From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Pitre Subject: Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking Date: Fri, 07 Aug 2009 10:18:14 -0400 (EDT) Message-ID: References: <4A7AEFA8.5010001@drmicha.warpmail.net> <4A7B95A8.2010000@vilain.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Sam Vilain , Nick Edelen , Michael J Gruber , Junio C Hamano , Jeff King , "Shawn O. Pearce" , Andreas Ericsson , Christian Couder , "git@vger.kernel.org" To: Johannes Schindelin X-From: git-owner@vger.kernel.org Fri Aug 07 16:19:04 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1MZQHe-0005dd-OH for gcvg-git-2@gmane.org; Fri, 07 Aug 2009 16:19:03 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757495AbZHGOSf (ORCPT ); Fri, 7 Aug 2009 10:18:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757399AbZHGOSf (ORCPT ); Fri, 7 Aug 2009 10:18:35 -0400 Received: from relais.videotron.ca ([24.201.245.36]:54848 "EHLO relais.videotron.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754082AbZHGOSe (ORCPT ); Fri, 7 Aug 2009 10:18:34 -0400 Received: from xanadu.home ([66.130.28.92]) by VL-MO-MR004.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KO000A6QFQEUV50@VL-MO-MR004.ip.videotron.ca> for git@vger.kernel.org; Fri, 07 Aug 2009 10:18:15 -0400 (EDT) X-X-Sender: nico@xanadu.home In-reply-to: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, 7 Aug 2009, Johannes Schindelin wrote: > Hi, > > On Fri, 7 Aug 2009, Nicolas Pitre wrote: > > > On Fri, 7 Aug 2009, Sam Vilain wrote: > > > > > Johannes Schindelin wrote: > > > >> the short answer is that cache slices are totally independant of > > > >> pack files. > > > >> > > > > > > > > My idea with that was that you already have a SHA-1 map in the pack > > > > index, and if all you want to be able to accelerate the revision > > > > walker, you'd probably need something that adds yet another mapping, > > > > from commit to parents and tree, and from tree to sub-tree and blob > > > > (so you can avoid unpacking commit and tree objects). > > > > > > > > > > Tying indexes together like that is not a good idea in the database > > > world. Especially as in this case as Nick mentions, the domain is > > > subtly different (ie pack vs dag). Unfortunately you just can't try to > > > pretend that they will always be the same; you can't force a full > > > repack on every ref change! > > > > Right. And the rev cache must work even if the repository is not > > packed. > > Umm, why? AFAICT the principal purpose of the rev cache is to help work > loads on, say, www.kernel.org. So what? Speeding up rev-list with a rev cache is completely orthogonal to whether the repository is packed or not. It is like having a "git diff" result cache: no one would think of stuffing that in the pack index. If we want to improve on the repository packing format, that must be doable without bothering with an independent concept such as a rev cache. > I am unlikely to notice the improvements in my regular "git log" calls > that only show a couple of pages before I quit the pager. Indeed. But what is your point again? Nicolas