Re: git clean performance issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



That looks like the same issue. The "use is_git_directory" approach
sounds good to me, is that the direction you would prefer? I can try
to cobble something together although I must warn you I have zero
previous experience with this code base so a few iterations will
probably be needed.

/Erik

On Sat, Apr 4, 2015 at 9:55 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Sat, Apr 04, 2015 at 08:32:45PM +0200, erik elfström wrote:
>
>> In my scenario get_ref_cache will be called 10000+ times, each time
>> with a new path. The final few calls will need to search through and
>> compare 10000+ entries before realizing that there is no existing
>> entry. This quickly ads up to 100 million+ calls to strcmp().
>>
>> From what I can understand, the calls to get_ref_cache in this
>> scenario will never do any useful work. Is this correct? If so, would
>> it be possible to bypass it, maybe by calling
>> resolve_gitlink_ref_recursive directly or by using some other way of
>> checking for the presence of a git repo in clean.c:remove_dirs?
>
> I think this is the same issue that was discussed here:
>
>   http://thread.gmane.org/gmane.comp.version-control.git/265560/focus=265585
>
> There is some discussion of a possible fix in that thread. I was hoping
> that Andreas was going to look further and produce a patch, but I
> imagine he got busy with other things. Do you want to try picking it up?
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]