This is the mail archive of the
mailing list for the GCC project.
Re: Git and GCC
- From: Johannes Schindelin <Johannes dot Schindelin at gmx dot de>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Giovanni Bajo <rasky at develer dot com>, Jakub Narebski <jnareb at gmail dot com>, Linus Torvalds <torvalds at linux-foundation dot org>, David Miller <davem at davemloft dot net>, jonsmirl at gmail dot com, peff at peff dot net, nico at cam dot org, harvey dot harrison at gmail dot com, ismail at pardus dot org dot tr, gcc at gcc dot gnu dot org, git at vger dot kernel dot org
- Date: Sat, 8 Dec 2007 12:00:41 +0000 (GMT)
- Subject: Re: Git and GCC
- References: <firstname.lastname@example.org> <20071207063848.GA13101@coredump.intra.peff.net> <email@example.com> <firstname.lastname@example.org> <alpine.LFD.email@example.com> <4759AC8E.firstname.lastname@example.org> <m3hciutaoq.fsf@roke.D-201> <1197069298.6118.1.camel@ozzu> <email@example.com>
On Fri, 7 Dec 2007, Daniel Berlin wrote:
> On 12/7/07, Giovanni Bajo <firstname.lastname@example.org> wrote:
> > On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
> > > > >> Is SHA a significant portion of the compute during these
> > > > >> repacks? I should run oprofile...
> > > > > SHA1 is almost totally insignificant on x86. It hardly shows up.
> > > > > But we have a good optimized version there. zlib tends to be a
> > > > > lot more noticeable (especially the *uncompression*: it may be
> > > > > faster than compression, but it's done _so_ much more that it
> > > > > totally dominates).
> > > >
> > > > Have you considered alternatives, like:
> > > > http://www.oberhumer.com/opensource/ucl/
> > >
> > > <quote>
> > > As compared to LZO, the UCL algorithms achieve a better
> > > compression ratio but *decompression* is a little bit slower. See
> > > below for some rough timings.
> > > </quote>
> > >
> > > It is uncompression speed that is more important, because it is used
> > > much more often.
> > I know, but the point is not what is the fastestest, but if it's fast
> > enough to get off the profiles. I think UCL is fast enough since it's
> > still times faster than zlib. Anyway, LZO is GPL too, so why not
> > considering it too. They are good libraries.
> At worst, you could also use fastlz (www.fastlz.org), which is faster
> than all of these by a factor of 4 (and compression wise, is actually
> sometimes better, sometimes worse, than LZO).
fastLZ is awfully short on details when it comes to a comparison of the
resulting file sizes.
The only result I saw was that for the (single) example they chose,
compressed size was 470MB as opposed to 361MB for zip's _fastest_ mode.
Really, that's not acceptable for me in the context of git.
Besides, if you change the compression algorithm you will have to add
support for legacy clients to _recompress_ with libz. Which most likely
would make Sisyphos grin watching them servers.