From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <gitster@pobox.com>
Cc: mhagger@alum.mit.edu, Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH 3/3] refs: use strings directly in find_containing_dir()
Date: Wed, 23 May 2012 19:15:34 +0200 [thread overview]
Message-ID: <4FBD1B36.5060404@lsrfire.ath.cx> (raw)
In-Reply-To: <7v4nr625vf.fsf@alter.siamese.dyndns.org>
Am 23.05.2012 18:56, schrieb Junio C Hamano:
> René Scharfe<rene.scharfe@lsrfire.ath.cx> writes:
>
>> Am 23.05.2012 00:18, schrieb Junio C Hamano:
>>> René Scharfe<rene.scharfe@lsrfire.ath.cx> writes:
>>>
>>>> What has git grep to do with refs? It checks if the path in the command
>>>> above is a ref, which makes it iterate over all of them..
>>>
>>> Do you mean:
>>>
>>> /* Is it a rev? */
>>> get_sha1()
>>> -> ...
>>> -> get_sha1_basic()
>>> -> dwim_ref()
>>>
>>> callpath?
>>
>> Yes, indeed. Hmm, this is done even if the paths come after a
>> double-dash. Anyway, I don't consider the check to be a performance
>> issue, just a quick way to test the allocation count that i stumbled
>> upon while working on the recent grep patches.
>
> I was merely reacting "iterate over all of them"; dwim_ref() only checks
> if .git/blah, .git/refs/heads/blah, .git/refs/tags/blah, etc. exists and
> the number of checks do not depend on the number of refs you have, so I
> was wondering if I overlooked something that does for_each_ref() of
> everything.
Yeah, for loose refs that's true. However, I have 470 packed refs, and
this command:
$ valgrind --tool=exp-dhat ./git grep guess xdiff/xutils.c
reports (among other findings):
==28255== max-live: 30,334 in 470 blocks
==28255== tot-alloc: 30,334 in 470 blocks (avg size 64.54)
==28255== deaths: none (none of these blocks were freed)
==28255== acc-ratios: 7.76 rd, 0.95 wr (235,582 b-read, 28,924 b-written)
==28255== at 0x402AEE8: malloc (in /usr/lib/valgrind/vgpreload_exp-dhat-x86-linux.so)
==28255== by 0x813691D: xmalloc (wrapper.c:50)
==28255== by 0x8106B1A: create_ref_entry.constprop.8 (refs.c:250)
==28255== by 0x8107761: read_packed_refs (refs.c:817)
==28255== by 0x810785F: get_packed_refs (refs.c:843)
==28255== by 0x8107BE7: resolve_ref_unsafe (refs.c:1028)
==28255== by 0x81090AA: dwim_ref (refs.c:1549)
==28255== by 0x8122E06: get_sha1_1 (sha1_name.c:304)
==28255== by 0x81237EF: get_sha1_with_context_1 (sha1_name.c:1044)
==28255== by 0x8124016: get_sha1 (cache.h:795)
==28255== by 0x75782F65: ???
René
next prev parent reply other threads:[~2012-05-23 17:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 13:16 [PATCH] find_containing_dir(): allocate strbuf less extravagantly mhagger
2012-05-22 17:34 ` Jeff King
2012-05-22 18:50 ` [PATCH 1/3] refs: convert parameter of search_ref_dir() to length-limited string René Scharfe
2012-05-22 18:50 ` [PATCH 2/3] refs: convert parameter of create_dir_entry() " René Scharfe
2012-05-22 18:50 ` [PATCH 3/3] refs: use strings directly in find_containing_dir() René Scharfe
2012-05-22 21:27 ` Junio C Hamano
2012-05-22 22:11 ` René Scharfe
2012-05-22 22:18 ` Junio C Hamano
2012-05-23 16:20 ` René Scharfe
2012-05-23 16:56 ` Junio C Hamano
2012-05-23 17:15 ` René Scharfe [this message]
2012-05-24 4:34 ` Michael Haggerty
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=4FBD1B36.5060404@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/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.