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

[PATCH 0/7] tweaking the delta base cache

From
Jeff King <peff@peff.net>
Date
Aug 22, 2016, 21:57 UTC
Message-ID
<20160822215725.qdikfcaz3smhulau@sigill.intra.peff.net>

After the experiments I did with --depth=50 recently, I noticed there seemed to be a lot of room for improvement in the delta-base-cache (and in particular, there seemed to be a lack of actual numbers).

So I tried a series of experiments, and these are the tweaks I came up with. There are a lot of numbers and analysis in the commit messages themselves. The most dramatic effect I got was that before this patch, bumping core.deltaBaseCacheLimit for the kernel gets you basically nothing, whereas with it, I get:

  core.deltaBaseCacheLimit    time to run git log -Sfoo --raw
  ------------------------    -------------------------------
                      128m    4m56.486s
                      256m    4m33.769s
                      512m    4m12.968s
                     1024m    3m32.623s

Note that I don't actually propose bumping the memory limit in this series. That's a bit more contentious, as it's really using more resources to do a space/time tradeoff, and people may not want to spend the RAM. Whereas this series just adjusts the actual data structures to let us use the RAM we've already been allocated more efficiently.

The interesting changes are really patches 5 and 6, which adjust the LRU management and the underlying hash structure.

There are a few ideas I thought of or saw in past threads but didn't explore. I don't plan on digging further on them right now, so if anybody else wants to do so, be my guest:

  - limiting the size of items entering the cache (e.g., to avoid a
    single giant blob blowing out all of the other entries)
  - something more clever than LRU, like weighting by a mix of size and
    recency
  - I didn't look at the criteria for adding entries to the cache at all
  - we seem to drop cache entries as we use them in unpack_entry(); I'm
    not sure if we would do better to retain them and let them leave via
    LRU expiration

So there may be more work, but I think these improvements stand on their own.

  [1/7]: cache_or_unpack_entry: drop keep_cache parameter
  [2/7]: clear_delta_base_cache_entry: use a more descriptive name
  [3/7]: release_delta_base_cache: reuse existing detach function
  [4/7]: delta_base_cache: use list.h for LRU
  [5/7]: delta_base_cache: drop special treatment of blobs
  [6/7]: delta_base_cache: use hashmap.h
  [7/7]: t/perf: add basic perf tests for delta base cache
-Peff
Next: Jeff King
Message 1 of 17 in “tweaking the delta base cache”
  1. 0/7 tweaking the delta base cacheJeff King, Aug 22, 2016
  2. 1/7 cache_or_unpack_entry: drop keep_cache parameterJeff King, Aug 22, 2016
  3. Junio C HamanoAug 23, 2016
  4. 2/7 clear_delta_base_cache_entry: use a more descriptive nameJeff King, Aug 22, 2016
  5. Junio C HamanoAug 23, 2016
  6. 3/7 release_delta_base_cache: reuse existing detach functionJeff King, Aug 22, 2016
  7. Junio C HamanoAug 23, 2016
  8. Jeff KingAug 24, 2016
  9. Junio C HamanoAug 24, 2016
  10. 4/7 delta_base_cache: use list.h for LRUJeff King, Aug 22, 2016
  11. Eric WongAug 22, 2016
  12. Jeff KingAug 23, 2016
  13. 5/7 delta_base_cache: drop special treatment of blobsJeff King, Aug 22, 2016
  14. Junio C HamanoAug 23, 2016
  15. 6/7 delta_base_cache: use hashmap.hJeff King, Aug 22, 2016
  16. Junio C HamanoAug 23, 2016
  17. 7/7 t/perf: add basic perf tests for delta base cacheJeff King, Aug 22, 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.