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

Re: Huge performance bottleneck reading packs

From
Jeff King <peff@peff.net>
Date
Oct 12, 2016, 23:18 UTC
Message-ID
<20161012231807.syockv2emrsjf55r@sigill.intra.peff.net>
In-Reply-To
<20161012230143.5kxcmtityaasra5j@sigill.intra.peff.net>
On Wed, Oct 12, 2016 at 07:01:43PM -0400, Jeff King wrote:
Show 28 quoted lines
> On Thu, Oct 13, 2016 at 12:30:52AM +0200, Vegard Nossum wrote:
> 
> > However, the commit found by 'git blame' above appears just fine to me,
> > I haven't been able to spot a bug in it.
> > 
> > A closer inspection reveals the problem to really be that this is an
> > extremely hot path with more than -- holy cow -- 4,106,756,451
> > iterations on the 'packed_git' list for a single 'git fetch' on my
> > repository. I'm guessing the patch above just made the inner loop
> > ever so slightly slower.
> > 
> > My .git/objects/pack/ has ~2088 files (1042 idx files, 1042 pack files,
> > and 4 tmp_pack_* files).
> 
> Yeah. I agree that the commit you found makes the check a little more
> expensive, but I think the root of the problem is calling
> prepare_packed_git_one many times. This _should_ happen once for each
> pack at program startup, and possibly again if we need to re-scan the
> pack directory to account for racing with a simultaneous repack.
> 
> The latter is generally triggered when we fail to look up an object we
> expect to exist. So I'd suspect 45e8a74 (has_sha1_file: re-check pack
> directory before giving up, 2013-08-30) is playing a part. We dealt with
> that to some degree in 0eeb077 (index-pack: avoid excessive re-reading
> of pack directory, 2015-06-09), but it would not surprise me if there is
> another spot that needs similar treatment.
> 
> Does the patch below help?

Also, is it possible to make the repository in question available? I might be able to reproduce based on your description, but it would save time if I could directly run gdb on your example.

Specifically, I'm interested in the call graph that leads to calling reprepare_packed_git().

-Peff
Previous: Jeff KingNext: Jeff King
Message 6 of 22 in “Huge performance bottleneck reading packs”
  1. Vegard NossumOct 12, 2016
  2. Junio C HamanoOct 12, 2016
  3. Vegard NossumOct 13, 2016
  4. Jeff KingOct 13, 2016
  5. Jeff KingOct 12, 2016
  6. Jeff KingOct 12, 2016
  7. Jeff KingOct 12, 2016
  8. Vegard NossumOct 13, 2016
  9. Jeff KingOct 13, 2016
  10. fetch: use "quick" has_sha1_file for tag followingJeff King, Oct 13, 2016
  11. Jeff KingOct 13, 2016
  12. Jeff KingOct 13, 2016
  13. Junio C HamanoOct 14, 2016
  14. Jeff KingOct 14, 2016
  15. Junio C HamanoOct 17, 2016
  16. Jeff KingOct 18, 2016
  17. Vegard NossumOct 13, 2016
  18. Jeff KingOct 13, 2016
  19. Vegard NossumOct 14, 2016
  20. Jeff KingOct 14, 2016
  21. Jakub NarębskiOct 14, 2016
  22. Vegard NossumOct 13, 2016

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.