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 30, 2014, 02:03 UTC
Message-ID
<CACsJy8CAhGT+dF511cbLZTEre9SKzs2EHfHaskuXh7sMTYL6JQ@mail.gmail.com>
In-Reply-To
<20140530000728.GC28683@sigill.intra.peff.net>
On Fri, May 30, 2014 at 7:07 AM, Jeff King <peff@peff.net> wrote:
Show 27 quoted lines
> But then we're just trusting that the "trust me" flag on disk is
> correct. Why not just trust that packed-refs is correct in the first
> place?
>
> IOW, consider this progression of changes:
>
>   1. Check refname format when we read packed-refs (the current
>      behavior).
>
>   2. Keep a separate file "packed-refs.stat" with stat information. If
>      the packed-refs file matches that stat information, do not bother
>      checking refname formats.
>
>   3. Put a flag in "packed-refs" that says "trust me, I'm valid". Check
>      the refnames when it is generated.
>
>   4. Realize that we already check the refnames when we write it out.
>      Don't bother writing "trust me, I'm valid"; readers can assume that
>      it is.
>
> What is the scenario that option (2) protects against that options (3)
> and (4) do not?
>
> I could guess something like "the writer has a different idea of what a
> valid refname is than we do". But that applies as well to (2), but just
> as "the reader who wrote packed-refs.stat has a different idea than we
> do".

The reader and the writer have to agree on the same "valid" definition or it wouldn't work. I don't suppose this packed-refs.stat idea would spread out to other implementations than C git, so we're still good. If we could write a flag in packed-refs saying "trust me" and other implementations will strip it when they update packed-refs, then we're good too.

Show 9 quoted lines
>
> As a side note, while it is nice that we might make check_refname_format
> faster, I think if you _really_ want to make repos with a lot of refs
> faster, it would make more sense to introduce an on-disk format that
> does not need linear parsing (e.g., something we could mmap and binary
> search, or even something dbm-ish that could be updated without
> rewriting the whole file (deletions, for example, must rewrite the
> whole file, giving quadratic performance when deleting all refs one by
> one).

Yeah, I bring up the idea because I think Mike's multiple ref backends is the way to go (assuming that it won't take as long as pack v4 development). If we assume we'll go with that, then we can keep the workaround to minimum.

-- 
Duy
Previous: Jeff KingNext: Michael Haggerty
Message 11 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.