Wustersoss schrieb:
Da stimme ich mit dir überein. Ich hatte auch nicht beabsichtigt da jetzt eine Diskussion auszulösen über performantes PHP. Wollte Maria lediglich aufzeigen wie sie ihr Problem lösen kann und habe dabei gleich mal einen Test draus gemacht um auf die Unterschiede hinzuweisen.
Ja, da sagst du was… Speziell ich (ich will da keinen Anderen mit reinreiten ;)) habe es in letzter Zeit irgendwie nicht so damit, das Topic beizubehalten. Das tut mir Leid, aber ich denke, solche Diskussionen sind dennoch ganz interessant.
Interessant finde ich aber deine Beispiele zur Testverfälschung, aber dass man sich da nicht auf andere verlassen sollte hast du ja bereits geschrieben.
Ich versuche immer darauf hinzuweisen, dass Benchmarks nicht zwingend ein brauchbarer Indikator sind. Es ist zwar durchaus möglich, gewisse Pauschalaussagen zu treffen („Einfache String-Funktionen sind – normalerweise – schneller als reguläre Ausdrücke.“). Aber erstens führen sie schnell zu falschen Schlüssen (siehe mein „Verfälschungsbeispiel“[1]), zweitens ist Optimierung nicht immer notwendig (Entwicklungszeit wird um 10 % verlängert für 1 % Performance-Gewinn in einem Bereich, in dem die Ausgaben ohnehin mit „Luft nach oben“ gecachet werden), drittens führen sie bei Mikrooptimierung gerne zu schwerer wartbarem Code, der einfach
zu „clever“ geschrieben ist.
-
Program optimization - Wikipedia, the free encyclopedia
[1] Zudem wird in der echten Anwendung ein Code eben zumeist nicht 10.000-mal hintereinander ausgeführt, sondern einmal. Das kann unterschiedliche Effekte ergeben, weil die Programmierung von Bibliotheken teilweise clever ist und Caching verwendet. Von der Optimierung, die PHP oder ein Betriebssystem eventuell vornehmen könnten, ganz zu schweigen. Das macht es schwierig, Benchmarks zu beurteilen, weil häufig nicht alle Hintergründe bekannt sind. (Tendenzen festzustellen, halte ich aber dennoch für absolut legitim.) Hier etwa ein Auszug aus der PCRE-Dokumentation:
SAVING PRECOMPILED PATTERNS FOR LATER USE
The compiled form of a regular expression can be saved and re-used at a
later time, possibly by a different program, and even on a host other
than the one on which it was compiled. Details are given in the
pcreprecompile documentation.
-
http://www.pcre.org/pcre.txt
Dieses Feature wird PHP vermutlich nutzen (ich habe nicht nachgeforscht). Die regulären Ausdrücke sind im
hier besprochenen Fall zwar dennoch langsamer. Aber der Dokumentationsausschnitt dürfte verdeutlichen, dass ein Test mit 10.000 Durchläufen nicht unbedingt die 10.000-fache Zeit eines einfachen Durchlaufs benötigt.
Ein Beispiel, das ich bei Performance-Fragen immer gerne heranziehe, ist der Unterschied zwischen substr und mb_substr.
PHP:
<?php // Datei-Encoding: UTF-8
mb_internal_encoding('UTF-8');
$__length = 100000;
$content = str_repeat('ä', $__length);
$count = strlen($content);
$timestart = microtime(true);
for ($i = 0; $i < $count; $i++) {
$unused = substr($content, $i, 1);
}
$timeend = microtime(true) - $timestart;
$diff = sprintf('%.3f', $timeend);
echo "substr brauchte " . $diff . " Sekunden um die Eingabe zeichenweise durchzugehen\n";
$content = str_repeat('ä', $__length);
$count = mb_strlen($content);
$timestart = microtime(true);
for ($i = 0; $i < $count; $i++) {
$unused = mb_substr($content, $i, 1);
}
$timeend = microtime(true) - $timestart;
$diff = sprintf('%.3f', $timeend);
echo "mb_substr brauchte " . $diff . " Sekunden um die Eingabe zeichenweise durchzugehen\n";
mb_substr braucht auf meinem Rechner mehr als 20-mal so lange wie substr. Das liegt daran, dass substr davon ausgehen kann, dass jedes Zeichen 1 Byte lang ist, während mb_substr je nach Zeichensatz analysieren muss, ob ein Zeichen möglicherweise mehrere Bytes umfasst. Das ist eine inhaltliche Sache, die ich als Programmierer im Zweifel einfach wissen muss, damit ich nicht zu falschen Schlüssen komme, denn mit
mb_internal_encoding('ASCII'); sind beide Tests praktisch gleich schnell. Es liegt also nicht an der Funktion, sondern an den Rahmenbedingungen.
