[quote=renee,06.04.2006, 07:52]@ptk: Gibt es Benchmarks, die zeigen, wie viel das alles ausmacht?[/quote]
Ich kenne kein Dokument, wo so etwas systematisch zusammengetragen wurde. Aber man bekommt solche Dinge mit, wenn man (wie ich früher) bei den perl5-porters mitliest. Einige Sachen sind klar: es macht einen Unterschied, ob man ohne Optimierung kompiliert oder mit -O oder -O2 oder noch höheren Optimierungsstufen. Unter Windows hat man die Wahl zwischen gcc und Visual C. Auch bei gcc hat sich was getan, angeblich soll 3.x besseren Code erzeugen als die Version 2.x.

Dann das Threading, wie Strat schon erwähnt hat, obwohl ich in diesem Zusammenhang eher Zahlen um 5% gehört habe. Beim Threading ist es klar, warum Perl dadurch langsamer wird: jede interne Perl-Funktionen benötigt einen zusätzlichen Parameter, nämlich den Perl-Interpreter. Und das auch, wenn gar keine Threads verwendet werden! Die Verlangsamung tritt ein, wenn Thread-Unterstützung nur einkompiliert ist.

Die Wahl des mallocs kann sich unterschiedlich auf die Geschwindigkeit auswirken. Man hat die Wahl zwischen der Perl-Implementation (-Dusemymalloc) oder der Betriebssystemvariante. Erstere geht meist verschwenderischer mit dem Speicher um und ist dafür schneller. Je nach Betriebssystem wird die eine oder andere Variante standardmäßig genommen, beispielsweise bei Linux ist es die glibc-Variante, bei FreeBSD die perl-Variante.

Ich habe damals meine Perls immer mit 64-Bit-Integer-Unterstützung gebaut (das geht auch auf 32-Bit-Maschinen). Einfach, weil ich es cool fand. Benötigt habe ich es nie. Wer weiß, wieviele Terazyklen ich deswegen unnötig verbraten habe :-)