From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Tue, 27 Sep 2011 07:59:24 GMT
Subject: Re: Git is not scalable with too many refs/*
Message-ID: <2ad152520590530dd1bdcfae9941ef9d@quantumfyre.co.uk>
In-Reply-To: <3539dab7-0fb2-4759-baaf-8e22efab2904@email.android.com>

On Mon, 26 Sep 2011 20:34:02 -0600, Martin Fick wrote:
>> Julian Phillips <julian@quantumfyre.co.uk> 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