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.
