Nun ohne Datenbank optimieren ist ganz schoen heavy. Vor allem weil sich PHP ganz anders verhaelt als man es erwartet. Wer haette gedacht dass die Funktionen in_array() und array_search() mit vergleich auf eine zahl und einem zahlenarray ca. 10mal langsamer sind als wenn diese zahlen als string mit strpos durchforstet werden. Ich sicher nicht, ist aber so! Zur Verdeutlichung:
$data = ' datum1 datum2 datum3 ... ';
if (strpos($data, ' datum999 ') !== false)
ist bei 10000 durchlaeufen und 1521 datensaetzen (zahl1 bis zahl1521) ca. 10 mal schneller als
$data = array(zahl1, zahl2, zahl3, ...);
if (in_array(zahl999, $data))
Grund koennte sein dass der PHP Interpreter meint er muesse selbst wenn er Zahlen mit Zahlen vergleich einen String-Vergleich durchfuehren.
array_search statt in_array ergibt keinen Unterschied, bei Nutzung von STRICT als true als dritten Parameter wird es nur minimal schneller.
Wenn uebrigens noch jemand eine Idee hat wie man quasi einen Pseudo-Hash als Array performant hinbekommt, bitte melden. Denn Sachen wie
$data = array(zahl1=>1, zahl2=>1, ...);
if (isset($data[999]))
sind wiederum 10mal so langsam wie der strpos auf String-Vergleich. Auch die Verwendung von array_key_exists hilft da nicht.
Willkommen in der PHP-Welt. Nichts ist so wie man es erwartet. Was nuetzt einem die beste "ich-kann-alles" Datenstruktur, wenn sie derart unperformant implementiert ist.. Merke: wenns auf Performance ankommt, verzichte auf Arrays, sie fressen nicht nur unter Umstaenden (insbes. assoziative Arrays koennen da richtig zulangen) ziemlich viel Speicher, sondern sind auch noch langsam. Alle Macht dem String, dies gilt aber nur fuer PHP (nach Zeitmessungen von Jojo koennte dies aber auch fuer VB6 gelten
). In jeder vernuenftigen Sprache duerften Zahlen-Arrays schneller sein, aber war PHP je eine vernuenftige "Sprache"?
vorherige Seite
Letzte Kommentare