Re: Lua 5.4.2 New assorted suggestions (Part II)

[Tim Hill <drtimhill@...>]

> On Nov 16, 2020, at 5:26 AM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:
> 
>> You know the first three rules of optimisation, right?  They are, in order:
>> 
>> 1. Measure
>> 2. Measure
>> 3. Measure
> 
> Also:
> 1. Don't.
> 2. Don't... yet.
> 3. Profile before optimizing
> 
> See for instance
> http://www.moscowcoffeereview.com/programming/the-3-rules-of-optimization/

I’ll be honest .. I REALLY dislike this “premature optimization” aphorism. It (and rules like it) are often quoted as if they are laws of physics, when in fact they are at best vague generalizations.

First, lua is already a *massively* optimized language, which is one of its attractions. The leanness of the language, VM, and libraries is a testament to that. So saying you should not optimize Lua seems dubious (I’m not defending the OPs changes, I’m talking in general here).

Second, the idea that optimization is something that can be “bolted on later” when something is found to be sub-performant applies only to certain very limited cases, mostly related to local implementation details. It certainly does NOT apply to, for example, architectural design, when “optimization” can often mean “start over”.  Should we use a bubble sort, and only later switch to (say) quicksort when we have carefully “proved” that it is too slow? Or write a video Codec in Perl, and then act surprised when it cannot process video data in real time?

What SHOULD be explained is that the choice of when to optimize (if ever) should be based on the *cost* of that optimization effort and the *probability* that it will be needed. Changing fundamental architectural design is massively expensive, as is re-writing a complex software system in a new language. That is why these decisions *must* be optimized up-front .. and quoting “we can optimize that later” is, in these cases, nonsense.

The very phrase “premature optimization” in fact gives a lie to itself. What do we mean by “permature”? If you mean “when you find the program does not perform as expected” then (as I have explained) you are going to be out of luck in most cases.


—TIm