bugmonotone - Bugs: bug #16601, [0.26 regression] Performance of...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #16601: [0.26 regression] Performance of checkout

Submitted by:  None
Submitted on:  Tue 16 May 2006 01:38:39 PM UTC  
Votes:  1  
 
Category: performanceSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed
mtn version --full: 

monotone 0.26 (base revision: unknown)
Running on : GNU/Linux
C++ compiler : GNU C++ version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)
C++ standard library: GNU libstdc++ version 20060115
Boost version : 1_33_1
Changes since base revision: unknown

Wed 20 Sep 2006 07:50:26 PM UTC, comment #5:

Awesome! And thanks for running those tests.

I suspect the change in memory usage has to do with changes in our cache infrastructure -- sqlite has a cache, we have some caches on top of it, they all have memory knobs, sqlite's cache's memory knob is tied to its block size, etc. All this stuff's undergone lots of fiddling lately, so I wouldn't be surprised if we've just bumped our total cache size somewhere... once things settle down a bit more, hopefully we'll remember to do some systematic investigation of what the trade-offs for these cache sizes are, and see how sensible we're being.

Nathaniel Smith <njs>
Project Member
Sun 17 Sep 2006 05:31:10 PM UTC, comment #4:

OK, the results are in. I used the same machine and same databases as in my previous testing, but this time the laptop was running on AC power, and so the processor was much faster. As a consequence, the difference between 0.24 and 0.26 is much smaller too.

Conclusions:

- the memory leak was indeed introduced in 0.25 and had moderate impact on performance
- the leak had much more impact on performance starting with 0.26
- versions after 0.26 do not show much difference
- 0.26 and later use up MUCH more memory than 0.25 and earlier, even after the leak is plugged.
- most importantly: fixing the leak does not only resolve the performance problem completely, but also allows 0.26 and later to outperform 0.25!

I'd like to rave a bit about performance. Monotone 0.24 was already the fastest version control system (as far as checkout was concerned) that I tried[1]; it was better than CVS, Meta-CVS, Mercurial, and Bazaar-NG. I think it is mostly due to compressing the database and thus reducing disk I/O when reading from it. With the leak fixed, it is even better.

[1] http://www.ada-france.org/debian/distributed-version-control-systems.html

To tone that down a bit: with the leak fixed, the VSIZE went from 37 Mb in <=0.25 to 74 Mb in >=0.26 (yes, that's +100%). This might affect people with little memory, or those who, like me, tend to constantly have something big compiling in the background :/

Overall, thanks a bunch for great software. I use monotone because I'm an Ada guy working in safety-critical avionics, and I love your attitude and programming style.

Measurements attached for the fun of it. Bug can be closed (canI do that myself? it seems not).

--
Ludovic Brenta, happy user.

Ludovic Brenta <lbrenta>
Project Member
Wed 13 Sep 2006 10:42:58 AM UTC, comment #3:

MMh. Looking back at the history (that's what version control is for, right?) I see that the leak was actually introduced in 0.25. In my initial report, I did mention a slowdown from 0.24 to 0.25, but at that time it wasn't that bad. The real problem came in 0.26, so I'm not sure that the leak is the only culprit (it may be, if the memory usage patterns in 0.26 trigger the leak more than in 0.25).

I'll experiment with 0.24 as reference, and all versions thereafter with and without the fix for the leak, and then I'll report back. That way, we'll know how much the leak contributed to the slowdown.

--
Ludovic Brenta.

Ludovic Brenta <lbrenta>
Project Member
Mon 04 Sep 2006 09:44:49 PM UTC, comment #2:

Sorry for not getting to this earlier -- we've been focusing on other bottlenecks.

0.26, like all versions of monotone, does SHA-1 all the data its writing during a checkout, but this only takes a few seconds on the tree sizes you're talking about.

We did just discover and fix a memory leak in the library Botan that monotone uses, which was causing excessive memory use and CPU time on checkout. (The memory leak was annoying, but worse was that it was triggering pathological behavior in Botan's memory subsystem, as it churned through all the leaked blocks trying to find unused ones.)

This has been fixed in e92c14ec2a376e9030a2f4808cbe1562560356a7, on current mainline, and the fix will be in 0.30 when it is released. If you could try your test case again with this or any more recent version, to confirm that this does fix the regression, that'd be appreciated -- or else if you could put up the databases so we could check ourselves. (We don't really have any good matching 0.25/0.26 database sets to play with, without some work.)

Nathaniel Smith <njs>
Project Member
Tue 16 May 2006 01:55:06 PM UTC, comment #1:

(Forgot to log in before submitting the bug report - so I am no longer anonymous :))

Ludovic Brenta <lbrenta>
Project Member
Tue 16 May 2006 01:38:39 PM UTC, original submission:

While evaluating Monotone for my own use, I have created two databases, one for 0.24 and one for 0.26, each containing several releases of the GCC sources (specifically, 3.4.[012345], 4.0.[012], 4.1.0, and the branch points for the 3.4, 4.0 and 4.1 branches). Thus there are 4 branches (including the trunk), only 14 changesets and 14 tags, but many many files in each database.

With Monotone 0.24, the database takes 183 Mb and checking out version 3.4.2 (in the middle of a branch) from the database takes 3.5 minutes. Updating the working copy to the head of the branch takes 2 minutes. Almost all of this time is disk access. The checkout takes 350 Mb.

With Monotone 0.25, the same checkout on the same machine takes 4.8 minutes, and the update takes 1.8 minutes. During that time, Monotone uses 20% of CPU, the rest is I/O.

With Monotone 0.26, the database takes 166 Mb and it takes 19 minutes to perform the same checkout on the same machine. During that time, Monotone takes 100% of CPU and 190 Mb of RAM.

I suspect that Monotone 0.26 might be recalculating the SHA1 sum of every file that it checks out; is that the case? I don't think that such a check is really worthwhile, since 'mtn diff' and 'mtn commit' already perform essentially the same check (unless I am missing something).

I can provide both databases on a dumb file server if someone needs them.

Thanks for your attention.

--
Ludovic Brenta.

Anonymous

 

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 1 encouragement so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Wed 20 Sep 2006 07:50:26 PM UTCnjsStatusNone=>Fixed
  Open/ClosedOpen=>Closed
Sun 17 Sep 2006 05:31:10 PM UTClbrentaAttached File-=>Added monotone-checkout-performance.txt, #10783
Tue 18 Jul 2006 09:17:10 PM UTCtommydCarbon-Copy-=>Added tommyd

Back to the top


Powered by Savane 3.1-cleanup1