From: Michael Schubert <mschub@elegosoft.com>
To: Marc Pegon <pegon.marc@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Sha1 lookup and GIT_USE_LOOKUP
Date: Fri, 10 Jun 2011 00:51:41 +0200 [thread overview]
Message-ID: <4DF14E7D.50809@elegosoft.com> (raw)
In-Reply-To: <BANLkTi=b+WKy2_9VeEw5B0QqodHfVJs2XQ@mail.gmail.com>
On 06/09/2011 11:24 AM, Marc Pegon wrote:
> On Wed, Jun 8, 2011 at 8:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Marc Pegon <pegon.marc@gmail.com> writes:
>>
>>> Since this environment variable is not set by default, git will always
>>> use a simple binary search, won't it ?
>>
>> Yes.
>>
>>> Also, when searching for a sha1 given a sha1 prefix, among packed
>>> objects, find_short_packed_object also does a simple binary search.
>>> Wouldn't it be simpler to just use the sha1_entry_pos method ?
>>
>> Unknown ;-).
>>
>> The environment variable is there exactly for people like you who are
>> interested in finding out which one yields better performance by
>> benchmarking. Once we can get a convincing result, we can either
>> deprecate the more involved sha1_entry_pos() if it turns out to be not
>> worth it, or we can always use it if it turns out to be significantly
>> better.
>
> Perhaps we could compare the two methods by counting for each one the
> average number of iterations it takes to find an object in a pack.
> But anyways, I guess GIT_USE_LOOKUP should also have an influence on
> the method used to find an object given a sha1 prefix, and the code
> that does a simple binary search should not be duplicated as it is
> now, right ?
The commit introducing sha1_entry_pos() comes with some reasoning:
628522
libgit2 dropped "old and boring binary search" some days ago:
dd453c
prev parent reply other threads:[~2011-06-09 22:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 18:31 Sha1 lookup and GIT_USE_LOOKUP Marc Pegon
2011-06-08 18:55 ` Junio C Hamano
2011-06-09 9:24 ` Marc Pegon
2011-06-09 22:51 ` Michael Schubert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DF14E7D.50809@elegosoft.com \
--to=mschub@elegosoft.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pegon.marc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.