From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29039 invoked by alias); 7 Dec 2007 23:04:49 -0000 Received: (qmail 29020 invoked by uid 22791); 7 Dec 2007 23:04:48 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0910.google.com (HELO rv-out-0910.google.com) (209.85.198.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Dec 2007 23:04:36 +0000 Received: by rv-out-0910.google.com with SMTP id f5so786985rvb for ; Fri, 07 Dec 2007 15:04:34 -0800 (PST) Received: by 10.141.83.15 with SMTP id k15mr3008082rvl.1197068674863; Fri, 07 Dec 2007 15:04:34 -0800 (PST) Received: from ?192.168.15.20? ( [98.207.63.2]) by mx.google.com with ESMTPS id b21sm424227rvf.2007.12.07.15.04.31 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2007 15:04:32 -0800 (PST) In-Reply-To: References: <20071206.193121.40404287.davem@davemloft.net> <20071207063848.GA13101@coredump.intra.peff.net> <9e4733910712062310s30153afibc44a5550fd9ea99@mail.gmail.com> <20071207.045329.204650714.davem@davemloft.net> <4759AC8E.3070102@develer.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Giovanni Bajo , Linus Torvalds , David Miller , jonsmirl@gmail.com, peff@peff.net, nico@cam.org, dberlin@dberlin.org, harvey.harrison@gmail.com, ismail@pardus.org.tr, gcc@gcc.gnu.org, git@vger.kernel.org Content-Transfer-Encoding: 7bit From: Luke Lu Subject: Re: Git and GCC Date: Fri, 07 Dec 2007 23:14:00 -0000 To: Jakub Narebski X-Mailer: Apple Mail (2.752.3) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00273.txt.bz2 On Dec 7, 2007, at 2:14 PM, Jakub Narebski wrote: > Giovanni Bajo writes: >> On 12/7/2007 6:23 PM, Linus Torvalds 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/ > > > 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. > > > It is uncompression speed that is more important, because it is used > much more often. So why didn't we consider lzo then? It's much faster than zlib. __Luke