gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chris Mason
Subject: Re: [Gnu-arch-users] [PATCH] arch speedups on big trees
Date: Tue, 06 Jan 2004 16:20:19 -0500

On Tue, 2004-01-06 at 16:13, Tom Lord wrote:
>     > From: Chris Mason <address@hidden>
> 
>     > Another small set of changes, directed at getting better speed from
>     > arch_make_changeset
> 
> I need to catch up with you.   May I impose on you to:

>   a) define some milestone at which you think I should merge from you
> 
Well, that depends on how much you like the ideas below ;-)

>   b) write up a (redundent with your other posts but useful as a
>      single entity) summary of your changes

Basically the changes have 3 major components, and some tweaks.

1) Maintain a reverse mapping of ids to the objects that own them.  This
lives in project_root/{arch}/++id-mapping, one file per id.  The name of
the file is the id in string form, and the contents of the file are the
path for the object owning it.  The reverse mapping allows
apply_changeset to inventory only the files involved in the changeset
being applied.

Most of the speed improvements come here, so I'm hoping I can convince
you it's a good idea.

2) add --link and --replace for tla add-pristine.  Having a hard linked
pristine tree makes commits faster, since the commit updates the
pristine tree as the last step.  The replace option lets you update an
existing pristine tree to a higher patch level without having to
inventory it again, it can make a big difference during star-merge.

I seem to remember a post where you talked about pristine trees being
dead, in my mind they are basically a private library.  It might be a
good idea later on to generalize them as such.

3) Avoid inode signatures for everything except library revisions. 
Since taking an inode signature involves a whole tree inventory, we
should only take them when we know we're going to read them at least
twice before snapping them again.  Otherwise, the inode sig is a net
loss in speed

The rest of the tweaks are pretty much gravy.  The changes are currently
in a big monolithic patch but I can pull things out if there's consensus
on the big 3 ideas above.  

-chris






reply via email to

[Prev in Thread] Current Thread [Next in Thread]