On Sat, Nov 20, 2010 at 01:02:25AM +0100, Valentin Villenave wrote: > On Sat, Nov 20, 2010 at 12:33 AM, Graham Percival > <[email protected]> wrote: > > If you want to improve our speed, then look into the "time" fields > > in the regtest comparison. It appears to be currently broken, but > > fixing this will likely be a 10-line patch. > > I didn't know about that;
This might be a good time to remind the bug squad that they are ALL supposed to look at the regtest comparison between versions. Even in Phil has already done it. Catching a regression ASAP, before the programmer forgets what he was doing, can cut the bugfix time by more than 50%. It is _well_ worth having a few duplicating a 5-minute task in case a few people fail to notice something. > is it in the tracker somewhere? No, go ahead. Add "maintainability". > > If you want to improve our memory handling, then look into the > > "cells:" fields in the regtest comparison. As far as I know > > they're working, but we have no documentation about what they > > mean, and the bug squad certainly isn't checking them. > > This could arguably be mentioned as another issue in the tracker, FWIW... Yes, go ahead. Add "maintainability". > > The best time to notice a drop in speed or memory importance is > > before a patch is pushed. The second-best time is after the devel > > release immediately following the commit. > > That doesn't mean we shouldn't have a more big-picture kind of vision. ... WTF do you think this is: > > Improving the regtest > > comparison code and docs will do more in the long term than any > > amount of complaining about this specific commit. That *is* the "big picture". If the "time" field is fixed, and the "time+cells" are documented, and if the bug squad followed the printed checklist in the CG, then we would never need Nick to go through and do benchmarks manually. In fact, if the first two items were done and we followed all the proposals for patch-handling that I'll be proposing in GOP, then we would never have an unexpected drop in performance in git. - Graham _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
