Optimisation

[Paul Makepeace]

On Tue, Mar 3, 2009 at 12:45 PM, Andy Armstrong <andy at hexten.net> wrote:
> On 3 Mar 2009, at 12:17, Nigel Peck wrote:
>>>
>>> Sounds like a definite case of premature optimisation.  If it's not
>>> causing issues for production code, ignore it.  If it is, then there's
>>> very likely much bigger problems....
>>
>> I'm just asking because I try to think about optimisation as I'm writing
>> code, rather than going back and doing it later, which I've only done in
>> rare cases.
>
>
> Think mainly about algorithm choice at write time - O(NlogN) always beats
> O(N^2).

It beats it only when the constant factors cancel. Often nlogn algos
have larger constant factors e.g. owing to simply more ops in the
process, so only start to win on larger n. IIRC Knuth says simple
sorts beat quicksort often up to n=1000, which in many scripting
scenarios is fair percentage of problems. (Not that anyone doesn't use
'sort' in perl but rather that going to the work of getting a lower
order algo needs justification in terms of expected large datasets,
and, realistically perf testing.)

> Go back and do performance tweaks like the one we're discussing only
> if the code proves too slow in practice.
>
> The rules of optmisation:
>
> Rule 1: don't optimise.
> Rule 2: (experts only) don't optimise - yet.

+1

P

>
> --
> Andy Armstrong, Hexten
>
>