Hi Johan, I'm thinking about it. I agree that graphs would be quite nice to have, and now that someone explicitly asked for it, I might be able to find a few cycles some time or other. Still, anyone else, feel free to chip in...
(To all, if you've been wondering what's up, I'm quite busy with non-svn issues these days, helping colleagues to meet deadlines and stuff.) ~Neels On 03/19/2012 11:12 AM, Johan Corveleyn wrote: > On Mon, Mar 19, 2012 at 2:52 AM, <ne...@apache.org> wrote: >> /home/neels/svnbench/20120319-002438 >> Started at Mon Mar 19 00:24:38 UTC 2012 >> >> *Disclaimer:* this tests only file://-URL access on a GNU/Linux VM. >> This is intended to measure changes in performance of the local working >> copy layer, *only*. These results are *not* generally true for everyone. >> >> Averaged-total results across all runs: >> --------------------------------------- >> >> COMPARE total_1.7.x to total_trunk > [...] > > Neels (or anyone), > > I think it would be (even more) interesting to see the evolution of > performance on trunk, from week to week. The comparisons with 1.7.x > are interesting, but it's difficult to see from these numbers that > something significantly changed relative to the week before. Getting a > more direct view onto the week-by-week evolution might help spot > improvements or regressions that were made in recent commits. > > Now, first of all this requires that the numbers can be compared over > time, which hinges on the stability of the perf-testsuite, and also > the stability of the machine and its environment. The former seems > relatively stable. I don't know about the latter. Is that (virtual) > machine relatively isolated from external influences etc... ? Can we > be relatively certain that no other processes run during the benchmark > etc? > > If those pre-conditions are met: would someone be able to do the work > of setting up something to process these numbers, creating nice tables > and/or graphs out of them showing the weekly evolution? Maybe even go > back to the last N reports and process them to include some historical > data? > > I don't have the cycles to implement this myself, so it's just a > suggestion. If someone can do this, I think it would be a valuable > tool for devs to keep an eye on performance. >
signature.asc
Description: OpenPGP digital signature
