Re: [Gnu-arch-users] Re: [PATCH] arch speedups on big trees

[Aaron Bentley]

On Fri, 2004-01-09 at 09:39, Chris Mason wrote:
> On Fri, 2004-01-09 at 09:22, Aaron Bentley wrote:
> > On Thu, 2004-01-08 at 17:51, Miles Bader wrote:
> > 
> > > 
> > > I don't know -- the current codebase doesn't seem to use
> > > arch_binary_files_differ before diffing; maybe your code-base does
> > 
> > His does, as does mine.
> > 
> > > Doing a binary comparison before diffing is a solution to this problem,
> > > but of course ends up reading the files twice.  
> > 
> > For hard-linked trees, my branch will avoid the read.
> 
> Vanilla arch tries to avoid the read as well, checking against the inode
> sig.  But it does this after restating the files, so an early check is a
> good thing (haven't read your patch, sorry).

Yes, it looked like that was what it was doing.  I'm using the inode and
device to determine if one file is the same as the other.

> A command to relink the project tree to the revision library or pristine
> tree will probably help keep the tree from slowing down over time.  

You could do "tla changes --relink" with very little pain, updating
links when files compare the same.

>The hard link stuff is a huge performance win.

Actually, I haven't seen a huge win where I expected to.  tla changes on
a hardlinked tree is just 1.05x faster than tla changes on a normal
tree.  The system time was pretty much the same.

Mind you, that was a pokey box, but you'd expect the system time to go
down, and it basically didn't.  Perhaps it was because I'd "primed" the
system by running tla changes first.

Anyone know of a utility that will clean out your cache?  Or would "grep
-r foo /" be the way to go?

Aaron
-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.