On Tue, 2 Apr 2013 02:45:17 +0300 Daniel Shahaf <danie...@elego.de> wrote:
> Daniel Shahaf wrote on Tue, Apr 02, 2013 at 02:42:52 +0300: > > Neels Hofmeyr wrote on Tue, Apr 02, 2013 at 01:29:09 +0200: > > > Somewhere between r1454789 and r1457253 on trunk, that's three to > > > four weeks ago, 'commit', 'copy' and 'merge' got dramatically > > > faster: as much as 80%, and more! Amazing. > > > > Ahem, you should probably correlate that with whenever our VM was > > moved to the shiny new VMs host. Hmm, would have been nice to know about this in advance :) Then again, I'd probably have to read *all* mails coming in to be sure that I wasn't notified, even those that don't contain my name. :P > Probably the easiest way to do this is by re-running the benchmark > against r1454789? This would be a good time to blow the entire collected benchmark data into the wind and start afresh. This is close to embarrassing. But can happen. That's why I keep including one-too-many disclaimers... This incident makes me much more careful, and I should rerun another benchmark on my home laptop to verify, next time I see amazing speed gain. (But until now, the benchmarks have been pretty consistent.) I *was* originally re-running against the "reference" revision numerous times every monday, but since the results were very consistent, I decided it would make more sense to not use so many CPU ticks and DB rows for nothing. I think it now runs one single 1.7.0 benchmark per week, which gets averaged out (read: ironed over) with all the previous runs. That could of course be cross checked to stay roughly unchanged, which isn't done yet. So we should see a gradual reduction of runtime improvement back to the previous ratings if we continued with the current database. Instead, I hope I'll soon find time to do a review of the benchmark commands themselves and just wipe the db in the process. Actually, wiping the db is quick ... db wiped. Benchmark review (and another wipe) pending. Do we have another host or two that could run benchmarks periodically? Then I'd only call results consistent if all three benchmarkers show similar change. Keep up the good work anyway, lads :) ~Neels
signature.asc
Description: PGP signature
