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

Re: [PATCH 0/3] lazily load commit->buffer

From
Jeff King <peff@peff.net>
Date
Jan 26, 2013, 22:14 UTC
Message-ID
<20130126221400.GA13827@sigill.intra.peff.net>
In-Reply-To
<7v8v7f1vqa.fsf@alter.siamese.dyndns.org>
On Sat, Jan 26, 2013 at 01:26:53PM -0800, Junio C Hamano wrote:
Show 24 quoted lines
> This looks very good.
> 
> I wonder if this lets us get rid of the hack in cmd_log_walk() that
> does this:
> 
>         while ((commit = get_revision(rev)) != NULL) {
>                 if (!log_tree_commit(rev, commit) &&
>                     rev->max_count >= 0)
>                         rev->max_count++;
> !               if (!rev->reflog_info) {
> !                       /* we allow cycles in reflog ancestry */
>                         free(commit->buffer);
>                         commit->buffer = NULL;
> !               }
>                 free_commit_list(commit->parents);
>                 commit->parents = NULL;
> 
> After log_tree_commit() handles the commit, using the buffer, we
> discard the memory associated to it because we know we no longer
> will use it in normal cases.
> [...]
> But that is a performance thing, not a correctness issue, so "we
> allow cycles" implying "therefore if we discard the buffer, we will
> show wrong output" becomes an incorrect justification.

Right. I think the correctness issue goes away with my patches, and it is just a question of estimating the workload for performance. I doubt it makes a big difference either way, especially when compared to actually showing the commit (even a single pathspec limiter, or doing "-p", would likely dwarf a few extra commit decompressions).

My HEAD has about 400/3000 non-unique commits, which matches your numbers percentage-wise. Dropping the lines above (and always freeing) takes my best-of-five for "git log -g" from 0.085s to 0.080s. Which is well within the noise. Doing "git log -g Makefile" ended up at 0.183s both before and after.

So I suspect it does not matter at all in normal cases, and the time is indeed dwarfed by adding even a rudimentary pathspec. I'd be in favor of dropping the lines just to decrease complexity of the code.

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 23 of 24 in “segmentation fault (nullpointer) with git log --submodule -p”
  1. ArminJan 23, 2013
  2. Jeff KingJan 23, 2013
  3. Stefan NäweJan 24, 2013
  4. Duy NguyenJan 24, 2013
  5. Stefan NäweJan 24, 2013
  6. Duy NguyenJan 24, 2013
  7. Jeff KingJan 24, 2013
  8. Junio C HamanoJan 24, 2013
  9. Jeff KingJan 25, 2013
  10. Duy NguyenJan 25, 2013
  11. Junio C HamanoJan 25, 2013
  12. Jeff KingJan 25, 2013
  13. Junio C HamanoJan 25, 2013
  14. Jonathan NiederJan 25, 2013
  15. Junio C HamanoJan 25, 2013
  16. Jonathon MahJan 25, 2013
  17. Junio C HamanoJan 25, 2013
  18. 0/3 lazily load commit->bufferJeff King, Jan 26, 2013
  19. 1/3 commit: drop useless xstrdup of commit messageJeff King, Jan 26, 2013
  20. 2/3 logmsg_reencode: never return NULLJeff King, Jan 26, 2013
  21. 3/3 logmsg_reencode: lazily load missing commit buffersJeff King, Jan 26, 2013
  22. Junio C HamanoJan 26, 2013
  23. Jeff KingJan 26, 2013
  24. Junio C HamanoJan 27, 2013

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.