Re: [PATCH v2 0/4] Speed up unpack_trees()
- From
Ben Peart <peartben@gmail.com>
- Date
- Jul 31, 2018, 17:31 UTC
- Message-ID
- <57d146a2-9bf8-66c9-9cb4-c05f93b63319@gmail.com>
- In-Reply-To
- <cc3c4dbb-d545-6a6c-b20e-6a8ca66fc210@gmail.com>
On 7/31/2018 12:50 PM, Ben Peart wrote:
> > > On 7/31/2018 11:31 AM, Duy Nguyen wrote:
Show 15 quoted lines
>> >>> 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