This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Git and GCC
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "Giovanni Bajo" <rasky at develer dot com>
- Cc: "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: Fri, 7 Dec 2007 18:33:26 -0500
- Subject: Re: Git and GCC
- References: <20071206.193121.40404287.davem@davemloft.net> <20071207063848.GA13101@coredump.intra.peff.net> <9e4733910712062310s30153afibc44a5550fd9ea99@mail.gmail.com> <20071207.045329.204650714.davem@davemloft.net> <alpine.LFD.0.9999.0712070919590.7274@woody.linux-foundation.org> <4759AC8E.3070102@develer.com> <m3hciutaoq.fsf@roke.D-201> <1197069298.6118.1.camel@ozzu>
On 12/7/07, Giovanni Bajo <rasky@develer.com> 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).