Re: Git is not scalable with too many refs/*

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

 



On Mon, 26 Sep 2011 20:34:02 -0600, Martin Fick wrote:
Julian Phillips <julian@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 26 Sep 2011 18:12:31 -0600, Martin Fick wrote:
That sounds a lot better.  Hopefully other commands should be faster
now too.

Yeah, I will try this in a few other places to see.

Thanks way much!!!

No problem.  Thank you for all the time you've put in to help chase
this down.  Makes it so much easier when the person with original
problem mucks in with the investigation.
Just think how much time you've saved for anyone with a large number of

those Gerrit change refs ;)

 Perhaps this is a naive question, but why are all these refs being
put into a list to be sorted, only to be discarded soon thereafter
anyway?  After all, git branch knows that it isn't going to print
these, and the refs are stored precategorized, so why not only grab
the refs which matter upfront?

I can't say that I am aware of a specific decision having been taken on the subject, but I'll have a guess at the reason:

The extra code it would take to have an API for getting a list of only a subset of the refs has never been considered worth the cost. It would take effort to implement, test and maintain - and it would have to be done separately for packed and unpacked cases to avoid still loading and discarding unwanted refs. All that to not do something that no-one has noticed taking any time? Until now, I doubt anyone has considered it something that was a problem - and now that even with 100k refs it takes less than a second, I doubt anyone will feel all that inclined to have a crack at it now either.

--
Julian
--
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]