Re: Ann: Natools.Chunked_Strings, beta 1

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2011-12-01, Yannick Duchêne <yannick_duchene@yahoo.fr> wrote:
> Le Thu, 01 Dec 2011 20:07:09 +0100, Jeffrey Carter  
><spam.jrcarter.not@spam.not.acm.org> a écrit:
>> The evil of premature optimization is the waste of effort when the  
>> optimization is unnecessary.
> Or also when optimization is at the cost of clarity (optimized  
> implementation is often less easy to understand and more error prone, as  
> it involves special cases everywhere).

That's what also I understood as "evil": when a trade-off between
optimization and clarity or simplicity or cleanness is shifted early
towards optimization. I don't consider a waste of time or effort as
"evil", only "bad" or "stupid". To reach the level of "evil" to my eyes,
it needs to be still costly after being unmasked as evil.

In the example here, in the case where I have a genuine performance
problem with Unbounded_String, and where Chunked_String turns out to be
as efficient, or slightly, that's exactly the same waste of time and
effort, without premature optimization or any evil.

Other the other hand, using an interface like String_Accumulator instead
of static calls, if it were only for performance consideration, and if
it turns out that the dynamic dispatch is doing irreparable damage to
performance, to the point of having to rewrite the thing with static
calls, then it would be evil because of the rewriting work needed repair
the code.

At least that's how I've always understood it. Re-reading the context of
Knuth's quote, "these attempts at efficiency actually have a strong
negative impact when debugging and maintenance are considered." The mere
existence of an optimized version of an existing module, that can be
plugged effortlessly into or out of the project, has no debugging or
maintenance impact at all.


Natasha