git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/3] refs: use strings directly in find_containing_dir()

From
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date
May 23, 2012, 17:15 UTC
Message-ID
<4FBD1B36.5060404@lsrfire.ath.cx>
In-Reply-To
<7v4nr625vf.fsf@alter.siamese.dyndns.org>
Am 23.05.2012 18:56, schrieb Junio C Hamano:
Show 28 quoted lines
> 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é
Previous: Junio C HamanoNext: Michael Haggerty
Message 11 of 12 in “find_containing_dir(): allocate strbuf less extravagantly”
  1. find_containing_dir(): allocate strbuf less extravagantlymhagger@alum.mit.edu, May 22, 2012
  2. Jeff KingMay 22, 2012
  3. 1/3 refs: convert parameter of search_ref_dir() to length-limited stringRené Scharfe, May 22, 2012
  4. 2/3 refs: convert parameter of create_dir_entry() to length-limited stringRené Scharfe, May 22, 2012
  5. 3/3 refs: use strings directly in find_containing_dir()René Scharfe, May 22, 2012
  6. Junio C HamanoMay 22, 2012
  7. René ScharfeMay 22, 2012
  8. Junio C HamanoMay 22, 2012
  9. René ScharfeMay 23, 2012
  10. Junio C HamanoMay 23, 2012
  11. René ScharfeMay 23, 2012
  12. Michael HaggertyMay 24, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.