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

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

[Gnu-arch-users] more speed improvements


From: Tom Lord
Subject: [Gnu-arch-users] more speed improvements
Date: Sun, 14 Sep 2003 10:53:35 -0700 (PDT)


Ok, this is a bit better.    Commits are actually starting to _feel_
notably faster.

I'm now seeing (relative to 1.1pre5) about a 3-5x real-time speed up
in what-changed and 5-8x real-time speed-up in inventory on my tla
trees.

To fully see the differences, you will need a fresh `get' of the trees
you want to try it on.

You will also have to build with the latest tla--devo--1.1 AND the
latest hackerlab--devo--1.0.


The cumulative optimizations/fixes include:

    a) Use inode signatures to avoid comparing files 
       when computing changesets against known revisions.

    b) Use inode signatures to key caching implicit and tagline 
       tags (avoid reading files looking for tags during
       inventory traversals).

    c) Avoid redundantly trying to open non-existing
       .arch-ids/=all and similar files.

    d) In Rx, actually use the available optimizations.


(d) is mildly interesting.   After beating back system calls with
(a..c) user time was still suprisingly high.   Some profiling revealed
that Rx was doing a huge amount of unecessary work because the test
that enabled a special-case optimization said (in essense) 

     if (x == 1)
        ... optimization applies ...;

instead of 

     if (x <= 1)
        ... optimization applies ...;

(If I tell you that x has a non-negative value, you can probably guess 
what it's value is when rx is called from tla during inventory
traversal :-)

In theory, the correction will make a significant difference on large
trees.  It will also cut back on the pressure against Rx's cache size.

Inventory-traversals with tag retrieval could never be as fast as a
simple `find(1)' traversal, but at least now they are in the same city
as the ballpark.

-t





reply via email to

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