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

Re: Decompression speed: zip vs lzo

From
MCMarco Costalba <mcostalba@gmail.com>
Date
Jan 10, 2008, 06:55 UTC
Message-ID
<e5bfff550801092255wc852252m9086567a88b1ae99@mail.gmail.com>
In-Reply-To
<alpine.LFD.1.00.0801092234130.3054@xanadu.home>
On Jan 10, 2008 4:41 AM, Nicolas Pitre <nico@cam.org> wrote:
Show 11 quoted lines
> On Wed, 9 Jan 2008, Johannes Schindelin wrote:
>
> > I agree that gzip is already fast enough.
> >
> > However, pack v4 had more goodies than just being faster; it also promised
> > to have smaller packs.
>
> Right, like not having to compress tree objects and half of commit
> objects at all.
>
>

Decompression speed has been shown to be a bottle neck on some tests involving mainly 'git log'.

Regarding back compatibility I really don't know at what level git functions actually need to know the compression format, looking at the code I would say at very low level, functions that deal directly with inflate() and friends are few [1] and not directly connected to UI, nor to git config. Is this compression format something user should know/care? and if yes why?

In my tests the assumption of a source files tar ball is unrealistic, to test the final size difference I would like testing different compressions on a big already packaged but still not zipped file. Someone could be so kind to hint me on how to create such a package with good quality, i.e. with packaging levels similar to what is done for public repos?

This does not realistically tests speed because as Junio pointed out the real decompressing schema is different: many calls on small objects, not one call on a big one. But if final size is acceptable we can go on more difficult tests.

Marco
[1] where inflate() is called:

-inflate_it() in builtin-apply.c -check_pack_inflate() in builtin-pack-objects.c -get_data() in builtin-unpack-objects.c -fwrite_sha1_file() in http-push.c and http-walker.c [mmm interesting same function in two files, also the signature and the contents seems the same....] -unpack_entry_data() in index-pack.c -unpack_sha1_header(), unpack_sha1_rest(), get_size_from_delta(), unpack_compressed_entry, write_sha1_from_fd() in sha1_file.c

Previous: Nicolas PitreNext: Marco Costalba
Message 34 of 39 in “Decompression speed: zip vs lzo”
  1. Marco CostalbaJan 9, 2008
  2. Junio C HamanoJan 9, 2008
  3. Sam VilainJan 9, 2008
  4. Johannes SchindelinJan 9, 2008
  5. Sam VilainJan 10, 2008
  6. Sam VilainJan 10, 2008
  7. Pierre HabouzitJan 10, 2008
  8. Nicolas PitreJan 10, 2008
  9. Linus TorvaldsJan 10, 2008
  10. Nicolas PitreJan 10, 2008
  11. Pierre HabouzitJan 11, 2008
  12. Sam VilainJan 10, 2008
  13. Linus TorvaldsJan 10, 2008
  14. Sam VilainJan 10, 2008
  15. Linus TorvaldsJan 10, 2008
  16. Sam VilainJan 11, 2008
  17. Linus TorvaldsJan 11, 2008
  18. Sam VilainJan 11, 2008
  19. Sam VilainJan 11, 2008
  20. Linus TorvaldsJan 11, 2008
  21. Sam VilainJan 12, 2008
  22. Nicolas PitreJan 12, 2008
  23. Sam VilainJan 12, 2008
  24. Nicolas PitreJan 12, 2008
  25. Johannes SchindelinJan 12, 2008
  26. Junio C HamanoJan 12, 2008
  27. Marco CostalbaJan 10, 2008
  28. Sam VilainJan 10, 2008
  29. Nicolas PitreJan 10, 2008
  30. Pierre HabouzitJan 11, 2008
  31. Nicolas PitreJan 11, 2008
  32. Morten WelinderJan 11, 2008
  33. Nicolas PitreJan 10, 2008
  34. Marco CostalbaJan 10, 2008
  35. Marco CostalbaJan 10, 2008
  36. Johannes SchindelinJan 10, 2008
  37. Marco CostalbaJan 10, 2008
  38. Dana HowJan 10, 2008
  39. Junio C HamanoJan 9, 2008

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.