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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).