|
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
[Prev in Thread] | Current Thread | [Next in Thread] |