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

Re: [PATCH] diff-delta: produce optimal pack data

From
CBCarl Baldwin <cnb@fc.hp.com>
Date
Feb 24, 2006, 20:40 UTC
Message-ID
<20060224204022.GA15962@hpsvcnb.fc.hp.com>
In-Reply-To
<Pine.LNX.4.64.0602241438521.31162@localhost.localdomain>
On Fri, Feb 24, 2006 at 03:02:07PM -0500, Nicolas Pitre wrote:
Show 5 quoted lines
> Well that is probably a bit tight.  Ideally it should be linear with the 
> size of the data set to process.  If you have 10 files 10MB each it 
> should take about the same time to pack than 10000 files of 10KB each.  
> Of course incrementally packing one additional 10MB file might take more 
> than a second although it is only one file.

Well, I might not have been fair here. I tried an experiment where I packed each of the twelve large blob objects explicitly one-by-one using git-pack-objects. Incrementally packing each single object was very fast. Well under a second per object on my machine.

After the twelve large objects were packed into individual packs the rest of the packing went very quickly and git v1.2.3's date reuse worked very well. This was sort of my attempt at simulating how things would be if git avoided deltification of each of these large files. I'm sorry to have been so harsh earlier I just didn't understand that incrementally packing one-by-one was going to help this much.

This gives me hope that if somehow git were to not attempt to deltify these objects then performance would be much better than acceptible.

[snip]
> However, if you could let me play with two samples of your big file I'd 
> be grateful.  If so I'd like to make git work well with your data set 
> too which is not that uncommon after all.

I would be happy to do this. I will probably need to scrub a bit and make sure that the result shows the same characteristics. How would you like me to deliver these files to you? They are about 25 MB deflated.

Carl
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        RADCAD (R&D CAD)
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Previous: Nicolas PitreNext: Nicolas Pitre
Message 11 of 35 in “diff-delta: produce optimal pack data”
  1. diff-delta: produce optimal pack dataNicolas Pitre, Feb 22, 2006
  2. Junio C HamanoFeb 24, 2006
  3. Nicolas PitreFeb 24, 2006
  4. Junio C HamanoFeb 24, 2006
  5. Carl BaldwinFeb 24, 2006
  6. Nicolas PitreFeb 24, 2006
  7. Carl BaldwinFeb 24, 2006
  8. Nicolas PitreFeb 24, 2006
  9. Carl BaldwinFeb 24, 2006
  10. Nicolas PitreFeb 24, 2006
  11. Carl BaldwinFeb 24, 2006
  12. Nicolas PitreFeb 24, 2006
  13. Carl BaldwinFeb 24, 2006
  14. Nicolas PitreFeb 25, 2006
  15. Linus TorvaldsFeb 24, 2006
  16. Nicolas PitreFeb 24, 2006
  17. Junio C HamanoFeb 24, 2006
  18. Nicolas PitreFeb 24, 2006
  19. Nicolas PitreFeb 24, 2006
  20. Linus TorvaldsFeb 25, 2006
  21. Nicolas PitreFeb 25, 2006
  22. Linus TorvaldsFeb 25, 2006
  23. Nicolas PitreFeb 25, 2006
  24. Nicolas PitreFeb 25, 2006
  25. [RFH] zlib gurus out there?Junio C Hamano, Mar 7, 2006
  26. Linus TorvaldsMar 8, 2006
  27. Junio C HamanoMar 8, 2006
  28. Linus TorvaldsMar 8, 2006
  29. Johannes SchindelinMar 8, 2006
  30. write_sha1_file(): Perform Z_FULL_FLUSH between header and dataSergey Vlasov, Mar 8, 2006
  31. Junio C HamanoMar 8, 2006
  32. Sergey VlasovMar 8, 2006
  33. Linus TorvaldsFeb 25, 2006
  34. Carl BaldwinFeb 24, 2006
  35. Nicolas PitreFeb 24, 2006

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.