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

Revisiting large binary files issue.

From
CBCarl Baldwin <cnb@fc.hp.com>
Date
Jul 10, 2006, 23:01 UTC
Message-ID
<20060710230132.GA11132@hpsvcnb.fc.hp.com>
Hi,

Some of this stuff has been discussed before but I thought I'd bring it up again.

I am using git in a way for which, admittedly, it was not intended. I have repositories in which I'm storing some source code mixed with some large binary files (from 20MB up to 1GB in the worst case). The large files easily dominate the space in the repository and the time that it takes to perform network operations between repositories.

Just to refresh your memory a sample of these files led to work that Nicolas did to improve the performance of packing large binary files. Thank you Nicolas, I think your work improved the speed of git in the face of largish files.

Attempting to delta compress these blobs is a frivolous effort. The nature of the blobs is such that if given two blobs: 'A', and the next revision, 'B' it is just as good --- from a pack-size standpoint --- to compress the entire contents of 'B' than try to find a delta from A -> B. It is also much faster than trying to find deltas. In git, I can accomplish this by setting the pack window (I think this is right) to 0.

When I set the window to 0 I one more issue. Even though the blobs are already compressed on disk I still seem to pay the penalty of inflating them into memory and then deflating them into the pack. When the window size is 0 this is just wasted cycles. With large binary files these wasted cycles slow down the push/fetch operation considerably. Couldn't the compressed blobs be copied into the pack without first deflating them in this 0 window case?

My 'porcelain' on top of git works around these issues by first rsyncing the object directories and then running the git push/fetch command afterward. The push/fetch command sees that the remote is up-to-date with all the necessary objects and skips packing. This works and is fast (much faster than even packing with window of 0 because of the time to inflate/deflate the objects) but I'd like to remove this work-around in the long-term.

Ideally, there are two things that I would like available with git to be able to remove my work-around.

First, I would like to be able to set the packing window to 0 for all of the git commands. It would be nice if I could set this in a per-repository config file so that any push/fetch operation would honor this window. Is there currently a way to do this?

Second, I would like to not pay the penalty to inflate and then deflate the objects into the pack when I use a window of 0. How hard would this be? I am a capable programmer and wouldn't mind getting my hands dirty in the code to implement this if someone could point me in the right direction.

Thanks for your time, Carl Baldwin

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Next: Junio C Hamano
Message 1 of 37 in “Revisiting large binary files issue.”
  1. Carl BaldwinJul 10, 2006
  2. Junio C HamanoJul 10, 2006
  3. Peter BaumannJul 11, 2006
  4. Linus TorvaldsJul 10, 2006
  5. [RFC]: Pack-file object format for individual objects (Was: Revisiting large binary files issue.)sf, Jul 11, 2006
  6. Linus TorvaldsJul 11, 2006
  7. sfJul 11, 2006
  8. Linus TorvaldsJul 11, 2006
  9. Linus TorvaldsJul 11, 2006
  10. Carl BaldwinJul 11, 2006
  11. Linus TorvaldsJul 11, 2006
  12. 1/3 Make the unpacked object header functions static to sha1_file.cLinus Torvalds, Jul 11, 2006
  13. 2/3 sha1_file: add the ability to parse objects in "pack file format"Linus Torvalds, Jul 11, 2006
  14. Johannes SchindelinJul 11, 2006
  15. Linus TorvaldsJul 11, 2006
  16. Johannes SchindelinJul 11, 2006
  17. Linus TorvaldsJul 11, 2006
  18. Johannes SchindelinJul 11, 2006
  19. Junio C HamanoJul 11, 2006
  20. sfJul 11, 2006
  21. Linus TorvaldsJul 11, 2006
  22. sfJul 11, 2006
  23. Junio C HamanoJul 11, 2006
  24. Linus TorvaldsJul 12, 2006
  25. Johannes SchindelinJul 12, 2006
  26. Linus TorvaldsJul 12, 2006
  27. Linus TorvaldsJul 12, 2006
  28. Junio C HamanoJul 12, 2006
  29. Linus TorvaldsJul 12, 2006
  30. Junio C HamanoJul 12, 2006
  31. Linus TorvaldsJul 12, 2006
  32. Peter BaumannJul 12, 2006
  33. Junio C HamanoJul 12, 2006
  34. Peter BaumannJul 12, 2006
  35. Linus TorvaldsJul 12, 2006
  36. Junio C HamanoJul 12, 2006
  37. 3/3 Enable the new binary header format for unpacked objectsLinus Torvalds, Jul 11, 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.