lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Braille export


From: David Kastrup
Subject: Re: Braille export
Date: Tue, 13 Nov 2012 14:49:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Mario Lang <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Taught me a lesson about "optimization" and "computer scientists".
>
> Yes, I know about the pitfalls that premature optimisation can open.
> In the case I was talking about, I actually went from roughly 70
> seconds runtime of my first naive implementation, to about 5 seconds
> now.  On the way, I discovered things like std::shared_ptr (basically
> reinventing GC for C++ :-) ).  Most of the remaining optimisations
> came from observing further improvements of the actual algorithm, and
> integrating it more closely with the language it is implemented in.
>
> So I guess both stories can happen: optimisation can be evil, but it
> can also lead to quite nice results.

Well, in the story at hand, optimisation was more or less a time sink,
both in the time it took to do the optimisation as well as the time it
took to understand and debug the program afterwards.

The actual key to performance was turning the data flow inside out: the
task was a correlation between grid data (regular) and height lines
(free form).  The original approach was running through the grid and
finding all corresponding free-form data, and my approach was running
through the free-form data and tracing its course through the grid
(using a variant of the Bresenham algorithm).

Any optimisation or even different programming language would have
distracted from the principal design error making the original program
slow, namely iterating through the regular data locations and finding
the corresponding free-form data locations rather than the other way
round.

It is a life-long learning experience to avoid time sinks.  Not just for
execution time, but also for maintenance time, whether it is your own or
that of others.

I find "Programming in Lua" an excellent book in that regard, focusing
on almost deceptively simple solutions to usually non-trivial problems.
Of course, the simplicity of the solutions is not entirely due to the
choice of programming language: in reality Lua is more an example for
minimalism rather than a necessary ingredient.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]