Hallo,
Es liegt hauptsächlich am Schreibzugriff - "copy-on-write" in den PHP-Arrays. Danke für die Erinnerungsstütze bezüglich der Bezeichnung.
was nicht wirklich überraschend ist: Der Kopiervorgang braucht etwas Zeit. Nicht viel, aber bei jedem ersten Schreiben auf ein Arrayelement ein bisschen.
Die Berechnung der Min/Max-Werte und deren textliche Ausgabe dauert aber nach der
- alten Methode (Ausführungszeit: 5.1807448863983sec)
- nach der geänderten Methode(Ausführungszeit: 4.7937939167023sec)
Also nahezu gleich lang. Hey, das sind nicht einmal 10% Unterschied, wird also einem durchschnittlichen Nutzer nicht auffallen.
Beide laden zunächst die Datei mit
file()
. Das funktioniert überraschenderweise allerdings auch in Nullkommanix.
Auch das finde ich nicht überraschend. Die PHP-Funktion file() ist in (mutmaßlich) sehr effizient geschriebenem C realisiert.
Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt.
Ich auch. Gespannt bin ich auch, ob sie dann wirklich praxistauglich ist, oder eher nur ein Proof of Concept.
Das Problem wird sein, dass ein String (Als classic-Array-Ersatz) aus 60.000 Datensätzen auch nicht in ein Datensegment passt und PHP da im Hintergrund ohnehin schon wieder basteln muss.
Nein. Denk dran, dass wir heute 32- oder 64-bit-Systeme haben. Die 64k-Segmentgrenzen von damals sind heute bedeutungslos. Heute kann eine Software mal eben so 48MB Speicherinhalt linear direkt adressieren (nur um eine Hausnummer zu nennen).
Alldings wird meine Ausgabevarable mit
$out .= ...
ja auch in allen Fällen in nahezu Nullzeit gefüllt und wieder gelesen Richtung Std-Out.
Was willst du damit andeuten?
Live long and pros healthy,
Martin
Ich stamme aus Ironien, einem Land am sarkastischen Ozean.