Så hurtigt som muligt

Hvis noget er helt ekstremt tidskritisk, så skal man være forsigtig
med ikke at ave for mange funktions-kald.

Ingen grund til helt at undgå dem, men undgåe dem inde i loops
og lignende.

Der er meget få applikationer der er så tidskritiske.

Og husk på, at hvis du f.eks. kan spare 10%, så svarer det 2 måneder så er
er CPU'erne 10% hurtigere og så kører den pæne kode acceptabelt !

Du kan jo prøve at måle lidt på forskellige konstruktioner.

Men ofte kan man finde andre og bedre måder at optimere på.

Hvis du skal kalde funktiner kan du evt. lave dem inline, sådan at den tid der går på skifte stack mm. ved funktionskald, spares.

Desuden skal du være opmærksom på, at du ved store rutiner ofte kan spare tid ved at compile med maximal optimering - det er ikke default.

Det er rigtig nok, at du sparer lidt tid til funktionskald o.lign. ved at undlade at bruge klasser og struktureret fremgangsmåde, etc., men jeg ville nok tænke mig om en ekstra gang, før jeg begyndte på dén slags.

Hvis der er nogen specielt kritiske funktioner kunne du evt. overveje at lave dem i assembler - men vær opmærksom på, at du skal være rigtig dygtig til det, hvis du skal være i stand til at lave noget, der er hurtigere end det, en moderne compiler genererer.

Det kommer selvfølgelig an på problemstillingen, hvad der vil være smartest at gøre.

Det kan også ofte betale sig at optimere på andet end ting der udføres i konstant tid. Fx har det stor betydning om eksekveringstiden vokser med n^2 eller log(n)*n, hvor n er størrelsen på input. Tjek fx alle løkker efter om de kan nøjes med at køre færre gange end først antaget. Denne form for optimering er nemmere hvis din kode er struktureret.

Og så er der det gode gamle citat (jeg har glemt hvem pokker det var der sagde det):

Premature optimization is the root of all evil.

Lav det du skal lave, og lav så nogle undersøgelser om det yder godt nok. Hvis ikke, så analyser problemet, find ud af hvor flaskehalse er, og så koncentrer dig om at optimere flaskehalse.

Det giver dig noget godt struktureret kode, som er til at vedligeholde (i hvert fald for størstedelen af det). Der vil så måske være dele af koden hvor du har optimeret så meget at det ikke er så nemt at se hvad pokker det laver. Der er det så vigtigt at dokumentere rigtig godt hvad pokker det er der foregår.

Og så vil jeg give tossen ret i det han skrev i det tidligere indlæg. Algoritmeoptimering giver som regel et bedre resultat.

Tid at lukke spørgsmålet ?