[linux-l] Re: Das ist zum Teufel nicht Linux

[Steffen Dettmer]

* Nico Golde wrote on Sun, Feb 26, 2006 at 12:47 +0100:
> > Auch bei rechenintensiven Programmen kann Bloat gut sein, wenn 
> > man Funktioncalls reduzieren kann (was durchaus eine Rolle 
> > spielen kann) oder man hier und da Sprünge/Verzweigungen 
> > vermeidet.
> 
> Da hast du zwar Recht, ich bin aber trotzdem der 
> Überzeugung, dass in es in der Praxis eher selten vorkommt, 
> dass viel Code auch die schnellerere Variante ist.

Ich denke, viel Code ist so gut wie immer die schnellere Variante. Bei
Optimierungen (ob nun per Hand oder per Compiler) kann man entweder auf
execution speed oder auf code size optimieren. Entweder mache ich viele
Calls in kleine Funktionen (langsam aber klein) oder in mach viel inline
(schnell aber gross). Muss ich Speicher sparen, muss ich wenig
redundante Datenstrukturen mit kleinen Algorithmen bearbeiten, kann ich
mit Speicher rumasen, kann ich Indicies und Hashes mitspeichern, falls
das Performance bringt, oder ich kann mir viel Zwischenergebnisse merken
und die Funktionen entsprechend erweitern, dass das benutzt wird.

Aber es ging ja um source code size, nicht um binary code size.
Sourcecodegrösse ist für den Compiler egal. Ob ich lange oder kurze
Variablen nehme, oder ob ich zusätzliche {}-Blöcke mache - der Code ist
in vielen Fällen sogar genau der gleiche. Selbst "temporäre Variablen",
die die Lesbarkeit erhöhen sollen, werden in der Regel wegoptimiert (und
nur ein Register wird benutzt). Daher sind Ausdrücke wie 
"(*(ptr++))[*(p++)]--" meist nicht mal schneller, als wenn man das
menschenlesbar in fünf Zeilen mit drei Variablen schreibt - oft kommt
wie gesagt der gleiche Assembler-code bei raus.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.