[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Derek Scherger
Subject: Re: [Monotone-devel] 0.17 "release candidate", last call for bugs...
Date: Sun, 13 Mar 2005 10:24:57 -0700
User-agent: Mozilla Thunderbird 1.0 (X11/20041231)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]