On Mon, Nov 17, 2008 at 2:11 PM, Giuseppe Bilotta
<giuseppe.bilotta@xxxxxxxxx> wrote:
> On Sun, Nov 16, 2008 at 6:34 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@xxxxxxxxx> writes:
>>> - my @headlist = git_get_heads_list(16);
>>> + my @headlist = git_get_heads_list(16, 'heads');
>>> + my @remotelist = $remote_heads ? git_get_heads_list(16, 'remotes') : ();
>>
>> Wasteful to run one for-each-ref for each list.
>>
>> You earlier introduced $ref_item{'class'} so that you can differenciate
>> what you got from git_get_heads_list(); make use of it, perhaps like:
>>
>> my @heads_list = git_get_heads_list(16, \%head_class);
>> my @headlist = grep { $_->{'class'} eq 'head' } @heads_list;
>> my @remotelist = grep { $_->{'class'} eq 'remote' } @heads_list;
>>
>> By the way, your [2/4] used "heads" and "remotes" as class, while your
>> [1/4] stored 'head' and 'remote' in $ref_item{'class'}. Notice the above
>> suggestion corrects this discrepancy as well.
>
> Although I agree with the head_class idea, I would like to point out
> that doing a single git call to retrieve all refs and then selecting
> the ones we want and doing multiple git calls are not equivalent.
>
> First of all, with multiple calls we can limit the calls to retrieve
> at most 16 refs of each kind, whereas this cannot be done with a
> single call for all the refs. I'm not sure however, performance-wise,
> if it's faster to filter the first 16 refs of each after retrieving
> all of them, or doing multiple calls, especially with lots of refs.
>
> Moreover, gitweb is already doing multiple for-each-ref calls to get
> tags and heads. I guess that at this point we could go the extra mile
> and include tags in the refs management. Of course, the problem of how
> to handle the rate limiting remains.
Sorry, replying to myself here. After more careful reading and some
more accurate testing, I gather that tags and heads management is
different enough to justify totally separate methods, and the cost of
an additional git call. It *could* still be merged (possibly with a
slightly different format string to accomodate both cases), but we
would have to do sorting ourselves, and such stuff. Not sure it's
worth it (yet).
My perplexity about rate limiting and separate calls for separate head
classes still remains, though.
--
Giuseppe "Oblomov" Bilotta
--
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
