Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

[Graham Percival]

On Sat, Nov 20, 2010 at 01:02:25AM +0100, Valentin Villenave wrote:
> On Sat, Nov 20, 2010 at 12:33 AM, Graham Percival
> <address@hidden> 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