Re: why is monotone so slow?

Peter Simons <simons@xxxxxxx> 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.