Re: [Gnu-arch-users] ANNOUNCEMENT -- "timestamps" optimization

[Jason McCarty]

Tom Lord wrote:
> 
> 
>     > From: Jason McCarty <address@hidden>
> 
>     > I did a little speed testing on Linux 2.4 (ext3 fs), with patch-160 and
>     > patch-162. Times reported are total time (including IO/system time).
> 
> To be clear: you mean that you tested on a 2.4 platform using the tla
> tree as your test case, right?

Right. The executables were produced from patch-160 and patch-162, and I
tested on a freshly checked out patch-162 project tree.

>     > User time was 2.7-2.8s on every run, so it looks like tree-traversal
>     > costs trump file-comparing costs, regardless of how many files are
>     > compared. 
> 
> For a tla-sized tree, that's not too surprising.  If you're testing
> against a much larger tree, that'd be surprising.

I don't think it would be surprising then either (considering user-time,
not total time). Considering that most source files are small (average
4.1KB for tla), the cost of comparing them is only a percentage of the
cost of finding them in the first place, considering that all the
dir-entries leading to them need to be read, and the files get statted,
and they are checked against the inventory regexps, .arch-ids, and for
taglines. But once a file and its corresponding pristine copy are in
memory, the cost of diffing them is almost nil when they have the same
contents.

But of course, unless there is plenty of free memory, IO costs (reduced
by this optimization) will trump all that.

>     > So the real effect of the inode-signature optimization is to
>     > reduce kernel cache usage, rather than reducing cpu time
>     > significantly.
> 
> That's right.   And for large trees (that press up against or past the
> cache size) that also means less disk i/o, which has been the apparent
> bottleneck on kernel-sized trees.

Yep, so it's certainly a big improvement on large trees or systems with
little memory.

Jason