[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: why is monotone so slow?
From: |
Bruce Stephens |
Subject: |
[Monotone-devel] Re: why is monotone so slow? |
Date: |
Tue, 14 Sep 2004 14:51:06 +0100 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) |
Peter Simons <address@hidden> writes:
[...]
> Well, frankly I'd expect the software to compile with aggressive
> optimizations whether it's worth it performance-wise or not, because
> everything else is a bug in either the code or the compiler, and the
> thought doesn't really please me.
It would be nice if the aggressive optimizations worked, sure.
> Besides, I'd be very surprised if in-lining didn't pay off. _Very_
> surprised.
I'd also be surprised if it had no effect. C++ complicates things a
bit, since short methods often get defined inside the class scope, and
so are inlined automatically.
In this particular case (with a largish source tree), I'd guess the
big cost is reading all the files and doing SHA1 on them. I remember
when this kind of problem hit Arch, and (eventually) code was put in
to remember mtime of checked out paths, and that means you just need
to do a stat, which turned out to be quicker (than doing a diff,
IIRC).
As far as I can see, monotone doesn't do that, so it doesn't have a
way to tell that a file is untouched except by calculating its hash.
I'm not suggesting that's a bad way to do things, but (if I'm right
about this) it's going to cause a performance problem on large trees.
It's the kind of thing I wouldn't build into a system to begin
with---it's not information that you'd stick into the repository, so
it should be an easyish optimisation whenever someone is bothered
enough to add it.
[Monotone-devel] Re: why is monotone so slow?, graydon hoare, 2004/09/14