Re: [Monotone-devel] 0.17 "release candidate", last call for bugs...

[Derek Scherger]

Georg-W. Koltermann wrote:
> The one big issue left that I have is performance.  I did a short
> benchmark of several revision control systems with a snapshot of my
> sourcecode, see attached screen shot (it's a gnumeric spreadsheet, I
> didn't know if it was a good idea to attach the data file as I was
> unsure how may of you would have gnumeric available, hence the screen
> shot).  Times are in seconds.  I have highlighted the problem areas.
>
> You will see that it is not practical to use monotone for this use case
> right now, it just eats up too much developer time.

How big is your source tree? I'm going to try and do some similar tests 
to see what I can see against a snapshot of the mozilla source tree 
(~26000 files) from a few months ago.

The problem I typically have is that oprofile only says that lots of 
time is spent in c++ collections code and not much about where in the 
monotone code the time is spent. I'm not much of a guru with oprofile 
though. :-/

At the moment add is still chugging away and it's been going for a while 
so I'd agree that performance needs some attention! Oooh... it just 
finished... 34 minutes, real time and user time almost agree so it's 
definitely working pretty hard.

I assume that you had only one or two revisions in the monotone database 
after your tests so they probably don't say anything about working with 
 a large graph of revisions? I think njs has done a bit of looking at 
this with the 75,000 revision gcc tree but I don't know what he found 
out there, other than, presumably there's also lots of room for improvement.

Cheers,
Derek