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

Re: [PATCH] check_refname_component: Optimize

From
Duy Nguyen <pclouds@gmail.com>
Date
May 29, 2014, 23:43 UTC
Message-ID
<CACsJy8BgriBBWJ6ZzQS8S7p4SUB=bdZHdnUQsyN03g+vtApbxA@mail.gmail.com>
In-Reply-To
<20140529234109.GA28683@sigill.intra.peff.net>
On Fri, May 30, 2014 at 6:41 AM, Jeff King <peff@peff.net> wrote:
Show 18 quoted lines
> On Fri, May 30, 2014 at 06:24:30AM +0700, Duy Nguyen wrote:
>
>> >> I wonder if we can get away without SSE code by saving stat info of
>> >> the packed-refs version that we have verified. When we read pack-refs,
>> >> if stat info matches, skip check_refname_component(). Assuming that
>> >> pack-refs does not change often, of course.
>> >
>> > Can you elaborate a bit more?
>>
>> The first time we read packed_refs, check_refname_format() is called
>> in read_packed_refs()->create_ref_entry() as usual. If we find no
>> problem, we store packed_refs stat() info in maybe packed_refs.stat.
>> Next time we read packed_refs, if packed_refs.stat is there and
>> indicates that packed_refs has not changed, we can make
>> create_ref_entry() ignore check_refname_format() completely.
>
> I'm confused. Why would we re-open packed-refs at all if the stat
> information hasn't changed?
No, not in the same process. In the next run.
Show 9 quoted lines
>
> read_packed_refs is only called from get_packed_ref_cache, and we only
> do so if !refs->packed. And refs->packed is only NULL if we haven't read
> the file yet, or it is stat-dirty.
>
> If that is working as intended, then we should generally only open and
> read packed-refs once per invocation of git.
>
> -Peff
-- 
Duy
Previous: Jeff KingNext: Jeff King
Message 9 of 15 in “check_refname_component: Optimize”
  1. 0/1 check_refname_component: OptimizeDavid Turner, May 28, 2014
  2. check_refname_component: OptimizeDavid Turner, May 28, 2014
  3. Michael HaggertyMay 28, 2014
  4. David TurnerMay 28, 2014
  5. Duy NguyenMay 29, 2014
  6. Junio C HamanoMay 29, 2014
  7. Duy NguyenMay 29, 2014
  8. Jeff KingMay 29, 2014
  9. Duy NguyenMay 29, 2014
  10. Jeff KingMay 30, 2014
  11. Duy NguyenMay 30, 2014
  12. Michael HaggertyMay 30, 2014
  13. Jeff KingMay 30, 2014
  14. Michael HaggertyMay 31, 2014
  15. Duy NguyenMay 31, 2014

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.