On Tue, 2 Apr 2013 02:45:17 +0300
Daniel Shahaf <danielsh_at_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
Keep up the good work anyway, lads :)
Received on 2013-04-02 15:13:38 CEST