ABAKUS

ein string vergleich auf ' datum ' mit strpos in einem string ' datum datum datum ... ' (enthaelt z.b. 1521 daten) soll ca. 10 mal schneller sein als die suche mit in_array in einem array von 1521 zahlenwerten.
das sagen meine zeitmessungen, und ich staune nur noch..

dabei spielt es kaum eine rolle ob die zahlenwerte als keys (geringfuegig schneller, zugriff quasi dann via isset(arrayName[key]) - auch eine referenz auf den hash hilft nicht) oder values (in_array) vorliegen.

denke aber dass in_array u.U. selbst schon schneller ist, aber das definieren des arrays die ganze zeit wegfrisst. auch serialize bzw. unserialize fuehren zu keinem speedup!

nochmal: unterm strich ist das definieren eines strings und anwendung von strpos zur suche einer zeichenkette darin ca. 10mal schneller ist als das definieren eines einfachen arrays mit zahlen und suchen mittels in_array nach einer zahl. sowas kann ja eigentlich nicht sein (zahlenvergleiche MUESSTEN immer schneller sein als stringvergleiche - sind sie wohl auch, aber php verplempert wohl viel ZUVIEL zeit fuers definieren eines arrays!), ist aber so. das naehrt mal wieder meine "hassliebe" auf diese "sprache"

suche eines datums in 1521 datensaetzen in pseudo-syntax, 10000 laeufe:

hashed double
if 1.oktett then array(2.oktett=>array(...),2.oktett=>..)
vergleich mit in_array nach zugriff ueber pseudo-hash
5.98043894768 s

pure trios as values
if 1. oktett then array(zahl,zahl,zahl...):
vergleich mit in_array
5.24863314629 s

pure trios as keys
if 1. oktett then array(zahl=>1,zahl=>1,...):
vergleich mit zugriff ueber pseudo-hash
4.91022896767 s

string mit daten, string-vergleich mit strpos the WINNER
if 1. oktett then string = ' datum datum datum ... ';
vergleich mit strpos auf ' datum '
0.598217010498 s

PS: mir ist klar dass diese messung ggf. je nach php & server config etc. anders ausfallen kann. daran kann man sich aber nicht orientieren wenn man eine loesung fuer alle (kleinster gemeinsamer nenner) sucht.

Wenn ich das richtig erinnere, läuft 'in_array' das Array durch und führt bei jedem Inhalt ein strpos durch, bei der Stringverarbeitung spart der Interpreter den Array-Durchlauf, welcher - je nach Grösse des Arrays - einige Zeit dauert ...


Gruss


codemonk

kann man in_array oder aehnlich beibringen dass es voelliger quatsch ist auf string zu vergleichen, also dass er zwingend auf zahlen vergleicht? oder bleibt mir nix anderes uebrig als ein for i=0 to len-1 .. und haendisch zu vergleichen, ggf. dann sogar mit binaerer suche ? gute idee, mal spaeter probieren ob das den speed rumreisst .. dachte halt in_array muesste hochoptimiert fuer genau so einen anwendungsfall sein. man staunt doch immer wieder

Check mal, wie schnell das bei Dir läuft ...

Auf meinem Server zu 'in_array' mehr als doppelt so schnell ...

<?php
function is_n($var)
{
if (preg_match("=^[0-9]+$=i",$var)) {
return TRUE;
} else {
return FALSE;
}
}
$a=array('bla','bla','10256');
for($x=0;$x<count($a);$x++) {
if(is_n($a[$x])==TRUE)//do something (z.B. strpos usw.)
}
?>


Gruss


codemonk

dein code wirft fragen auf, denn:
dort wird nur verglichen ob es sich um eine zahl handelt oder sowas, und das mit einem preg_match ausdruck der i.d.r 6mal langsamer ist als z.b. strpos. hinzu kommt dass man nicht innerhalb der schleife jedesmal neu den count ermitteln sollte -> tipp

ich hab ihn dennoch ausprobiert. er war mit den 3 werten im array 6mal schneller als strpos, aber das lag auch an den 3 werten. ich hab daraufhin ca. 30 werte ins array gehauen und schon war er nur noch halb so schnell wie strpos mit 1521 werten

das problem scheint tiefer verwurzelt zu sein.

hab ich auch noch gemessen:
eine FOR schleife statt ein in_array ist uebrigens ca. 50% langsamer.. -> wenigstens etwas logik bleibt in PHP erhalten

Zitat:
"ich hab ihn dennoch ausprobiert ..."

Mit welcher PHP-Version?


Gruss


codemonk

PHP Version 5.1.2

das str_pos wird vermutlich über einen automaten realisiert, das geht ziemlich zügig.
bei nem arrray hast du noch den ganzen array-overhead. klingt für mich logisch, dass str_pos schneller ist.

kann man bei den arrays nicht erzwingen dass sie einfach nur als zahlen hintereinander im speicher abgelegt werden und ebenso bei einem vergleich nur auf zahlen geprueft werden? wahrscheinlich nich..

heisst das nun ich muss mich dann in php von arrays ganz verabschieden wenns um grosse daten-container _und_ performance geht? gibts noch eine alternative datenstruktur die schnell waere, ausser ggf. eine binaere [da fuehlt man sich fast an peek & poke erinnert]?

wer jetzt mit xml kommt, wird ausgepeitscht - das ist definitiv noch langsamer