On 7/31/2018 12:50 PM, Ben Peart wrote:
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
In the performance game of whack-a-mole, that call to repair cache-tree
is now looking quite expensive...
Yeah and I think we can whack that mole too. I did some measurement.
Best case possible, we just need to scan through two indexes (one with
many good cache-tree, one with no cache-tree), compare and copy
cache-tree over. The scanning takes like 1% time of current repair
step and I suspect it's the hashing that takes most of the time. Of
course real world won't have such nice numbers, but I guess we could
maybe half cache-tree update/repair time.
I have some great profiling tools available so will take a look at this
next and see exactly where the time is being spent.
Good instincts. In cache_tree_update, the heavy hitter is definitely
hash_object_file followed by has_object_file.
Name Inc % Inc
+ git!cache_tree_update 12.4 4,935
|+ git!update_one 11.8 4,706
| + git!update_one 11.8 4,706
| + git!hash_object_file 6.1 2,406
| + git!has_object_file 2.0 813
| + OTHER <<vcruntime140d!strchr>> 0.5 203
| + git!strbuf_addf 0.4 155
| + git!strbuf_release 0.4 143
| + git!strbuf_add 0.3 121
| + OTHER <<vcruntime140d!memcmp>> 0.2 93
| + git!strbuf_grow 0.1 25
