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

Preferring shallower deltas on repack

From
Brian Downing <bdowning@lavos.net>
Date
Jul 9, 2007, 04:43 UTC
Message-ID
<20070709044326.GH4087@lavos.net>

SBCL, a Lisp implementation, has a file in their (CVS) repository called "version.lisp-expr" which is updated every commit. This file looks like:

------------------------------------------------------------------------ ;;; This is the master value for LISP-IMPLEMENTATION-VERSION. It's ;;; separated into its own file here so that it's easy for ;;; text-munging make-ish or cvs-ish scripts to find and tweak it. For ;;; the convenience of such scripts, only a simple subset of Lisp ;;; reader syntax should be used here: semicolon-delimited comments, ;;; possible blank lines or other whitespace, and a single ;;; double-quoted string value alone on its own line. ;;; ;;; ANSI says LISP-IMPLEMENTATION-VERSION can be NIL "if no ;;; appropriate and relevant result can be produced", but as long as ;;; we control the build, we can always assign an appropriate and ;;; relevant result, so this must be a string, not NIL. ;;; ;;; Conventionally a string like "0.6.6", with three numeric fields, ;;; is used for released versions, and a string like "0.6.5.xyzzy", ;;; with something arbitrary in the fourth field, is used for CVS ;;; checkins which aren't released. (And occasionally for internal ;;; versions, especially for internal versions off the main CVS ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".) "1.0.7.10" ------------------------------------------------------------------------

Only very rarely does anything but the last line change.

The current repack implementation, when given values like "--window=100 --depth=1000", happily generates an incredibly deep tree for this file, maxing out the depth. (I'm only using such a high depth to demonstrate the pessimal behavior.) I noticed that it just takes the first delta it finds that is the smallest; it then only looks for deltas with a max_size of the old size - 1, so it can never find better matches with regard to depth.

I modified this to prefer shallower deltas of the same size.  This made
the deltas for this file a very wide tree with a maximum depth of about
65.  Other (much smaller) improvements were seen elsewhere in the pack.
Runtime does not seem to have been affected, as most of the work had
already been done when it was tossing deltas before.
Some simple statistics:
SBCL, standard pack-objects, window 100, depth 1000:
  Max depth: 980
  Mean depth: 100.223622114502
  Median depth: 12
  Standard deviation: 188.214331919176
SBCL, patched pack-objects, window 100, depth 1000:
  Max depth: 787
  Mean depth: 61.5669990817656
  Median depth: 11
  Standard deviation: 127.644652607399
git, standard pack-objects, window 100, depth 1000:
  Max depth: 925
  Mean depth: 77.184264479754
  Median depth: 8
  Standard deviation: 150.112998198182
git, patched pack-objects, window 100, depth 1000:
  Max depth: 913
  Mean depth: 74.9981877425496
  Median depth: 7
  Standard deviation: 147.900721785959

The only negative effect I could see from this patch might be pack locality. Unfortunately I don't know enough (read: anything) about pack access patterns to determine if this is the case.

Patch to follow.
-bcd
Next: Brian Downing
Message 1 of 19 in “Preferring shallower deltas on repack”
  1. Brian DowningJul 9, 2007
  2. pack-objects: Prefer shallower deltas if the size is equalBrian Downing, Jul 9, 2007
  3. Junio C HamanoJul 9, 2007
  4. Junio C HamanoJul 9, 2007
  5. Brian DowningJul 9, 2007
  6. Junio C HamanoJul 9, 2007
  7. Brian DowningJul 9, 2007
  8. Nicolas PitreJul 9, 2007
  9. Junio C HamanoJul 9, 2007
  10. Brian DowningJul 9, 2007
  11. Nicolas PitreJul 9, 2007
  12. Brian DowningJul 9, 2007
  13. Brian DowningJul 9, 2007
  14. Nicolas PitreJul 9, 2007
  15. Brian DowningJul 9, 2007
  16. Shoddy pack information toolBrian Downing, Jul 9, 2007
  17. Junio C HamanoJul 11, 2007
  18. Pack information toolBrian Downing, Jul 12, 2007
  19. Linus TorvaldsJul 9, 2007

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.