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

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

Re: [Gnu-arch-users] larger trees slowing down


From: Dustin Sallings
Subject: Re: [Gnu-arch-users] larger trees slowing down
Date: Tue, 27 Jan 2004 10:02:58 -0800


On Jan 27, 2004, at 6:45, Tom Lord wrote:

122 patches will always take longer than, say 5 or 6 but what was most
likely making things particularly slow in that environment is some
combination of slow disk access and small memory (kernel caches
especially).

You don't mention if you were adding all 122 revisions to a library or
not.  The baseline work there would include O(122) tree traversals
which, if not cached and of a slow filesystem....

This is an example of why you might to toss in the occasional cacherev
and/or library update.

I apologize for this being vague, but I'm approaching this from more of a user point of view (one who doesn't know why the library is useful).

        Here's what I've got:

        An archive with 2322 patches from a base.

        A cacherev at 2200.

The final tree seems to have 2,711 entries outside of {arch} and about 7,296 entries in {arch}.

With this, I'm checking out a tree from scratch (plain tla get). It took 17 minutes. I was on a fairly old ibook on battery, so I imagine it wasn't the best performing filesystem I've used, but 17 minutes is averaging something like 8.3 seconds per patch.

The surprising part is that applying an individual patch (at least as part of get) seems rather slow, even though they're mostly very small patches. Replay actually applies the patches fairly quickly, though.

--
Dustin Sallings





reply via email to

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