Hello, > > Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht. > > Dann optimierst du möglicherweise an der falschen Stelle. Es gibt eine Faustregel die bessagt, dass ein Programm geschätzte 90% der Laufzeit in 10% des Codes verbringt. Es hilft also in der Regel recht wenig auf Verdacht zu optimieren, weil man dann mit hoher Wahrscheinlichkeit nur sehr kleine Potenziale ausschöpfen kann. Es ist viel effektiver auf Sicht zu fahren, und erstmal die Engpässe zu ermitteln und sich eine Übersicht der Lage zu verschaffen. Dafür gibt es extra Werkzeuge. xdebug hat bspw. auch einen Profiler integriert, damit kann man eine detaillierte Aufzeichnung des Laufzeitverhaltens erstellen. Betrachten und auswerten kann man die Aufzeichnungen dann mit KCachegrind. Wenn du dann den Engpass gefunden hast, dann weißt du auch, wo hohes Optimierungspotenzial liegt und kannst dann gezielt optimieren. Vielen Dank für deine Unterstützung. Die verantwortliche Stelle habe ich schon gefunden und dort auch eingegriffen. Es liegt hauptsächlich am Schreibzugriff - "copy-on-write" in den PHP-Arrays. Danke für die Erinnerungsstütze bezüglich der Bezeichnung. > > Es scheint mir hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen. > > Meinst du copy-on-write? Das ist eine Perforamnce-Optimierung, sie macht Code in der eher Regel schneller als langsamer. Das stimmt, solange man eben **nicht** schreibend (ändernd) zugreift. In meinem Versuchsbeispiel sieht man das auch ganz deutlich. Der Aufbau der Grafikseite aus denselben z. Zt. ca. 60.000 Datensätzen geht in Nullkommanix. 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) Die alte Methode hat den Vorteil, dass die Datei nicht sortiert sein muss. Die neue arbeitet mit klassischem Gruppenwechsel. Beide laden zunächst die Datei mit `file()`. Das funktioniert überraschenderweise allerdings auch in Nullkommanix. Die grafischen Anzeigen nutzten auch `file()`. Wenn ich mehr getestet habe, schiebe ich die Codes noch hinterher. Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt. Und noch eine Bemerkung zum Schluss: ich wollte hier gar nichts "optimieren", bin nur gebeten worden, einen Unterschied zu ermitteln zwischen PHP-Arrays und klassischen statischen Arrays. Da es die in PHP eigentlich gar nicht offen zugänglich gibt für den Anwendungsprogrammierer, muss ich mir eben eine Krücke ausdenken. 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. Alldings wird meine Ausgabevarable mit `$out .= ...` ja auch in allen Fällen in nahezu Nullzeit gefüllt und wieder gelesen Richtung Std-Out. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, > > Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht. > > Dann optimierst du möglicherweise an der falschen Stelle. Es gibt eine Faustregel die bessagt, dass ein Programm geschätzte 90% der Laufzeit in 10% des Codes verbringt. Es hilft also in der Regel recht wenig auf Verdacht zu optimieren, weil man dann mit hoher Wahrscheinlichkeit nur sehr kleine Potenziale ausschöpfen kann. Es ist viel effektiver auf Sicht zu fahren, und erstmal die Engpässe zu ermitteln und sich eine Übersicht der Lage zu verschaffen. Dafür gibt es extra Werkzeuge. xdebug hat bspw. auch einen Profiler integriert, damit kann man eine detaillierte Aufzeichnung des Laufzeitverhaltens erstellen. Betrachten und auswerten kann man die Aufzeichnungen dann mit KCachegrind. Wenn du dann den Engpass gefunden hast, dann weißt du auch, wo hohes Optimierungspotenzial liegt und kannst dann gezielt optimieren. Vielen Dank für deine Unterstützung. Die verantwortliche Stelle habe ich schon gefunden und dort auch eingegriffen. Es liegt hauptsächlich am Schreibzugriff - "copy-on-write" in den PHP-Arrays. Danke für die Erinnerungsstütze bezüglich der Bezeichnung. > > Es scheint mir hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen. > > Meinst du copy-on-write? Das ist eine Perforamnce-Optimierung, sie macht Code in der eher Regel schneller als langsamer. Das stimmt, solange man eben **nicht** schreibend (ändernd) zugreift. In meinem Versuchsbeispiel sieht man das auch ganz deutlich. Der Aufbau der Grafikseite aus denselben z. Zt. ca. 60.000 Datensätzen geht in Nullkommanix. 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) Die alte Methode hat den Vorteil, dass die Datei nicht sortiert sein muss. Die neue arbeitet mit klassischem Gruppenwechsel. Beide laden zunächst die Datei mit `file()`. Das funktioniert überraschenderweise allerdings auch in Nullkommanix. Die grafischen Anzeigen nutzten auch `file()`. Wenn ich mehr getestet habe, schiebe ich die Codes noch hinterher. Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt. Und noch eine Bemerkung zum Schluss: ich wollte hier gar nichts "optimieren", bin nur gebeten worden, einen Unterschied zu ermitteln zwischen PHP-Arrays und klassischen statischen Arrays. Da es die in PHP eigentlich gar nicht offen zugänglich gibt für den Anwendungsprogrammierer, muss ich mir eben eine Krücke ausdenken. 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. Alldings word meine Ausgabevarable mit `$out .= ...` ja auch in allen Fällen in nahezu Nullzeit gefüllt. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, > > Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht. > > Dann optimierst du möglicherweise an der falschen Stelle. Es gibt eine Faustregel die bessagt, dass ein Programm geschätzte 90% der Laufzeit in 10% des Codes verbringt. Es hilft also in der Regel recht wenig auf Verdacht zu optimieren, weil man dann mit hoher Wahrscheinlichkeit nur sehr kleine Potenziale ausschöpfen kann. Es ist viel effektiver auf Sicht zu fahren, und erstmal die Engpässe zu ermitteln und sich eine Übersicht der Lage zu verschaffen. Dafür gibt es extra Werkzeuge. xdebug hat bspw. auch einen Profiler integriert, damit kann man eine detaillierte Aufzeichnung des Laufzeitverhaltens erstellen. Betrachten und auswerten kann man die Aufzeichnungen dann mit KCachegrind. Wenn du dann den Engpass gefunden hast, dann weißt du auch, wo hohes Optimierungspotenzial liegt und kannst dann gezielt optimieren. Vielen Dank für deine Unterstützung. Die verantwortliche Stelle habe ich schon gefunden und dort auch eingegriffen. Es liegt hauptsächlich am Schreibzugriff - "copy-on-write". Danke für die Erinnerungsstütze bezüglich der Bezeichnung. > > Es scheint mir hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen. > > Meinst du copy-on-write? Das ist eine Perforamnce-Optimierung, sie macht Code in der eher Regel schneller als langsamer. Das stimmt, solange man eben **nicht** schreibend (ändernd) zugreift. In meinem Versuchsbeispiel sieht man das auch ganz deutlich. Der Aufbau der Grafikseite aus denselben z. Zt. ca. 60.000 Datensätzen geht in Nullkommanix. 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) Die alte Methode hat den Vorteil, dass die Datei nicht sortiert sein muss. Die neue arbeitet mit klassischem Gruppenwechsel. Beide laden zunächst die Datei mit `file()`. Das funktioniert überraschenderweise allerdings auch in Nullkommanix. Die grafischen Anzeigen nutzten auch `file()`. Wenn ich mehr getestet habe, schiebe ich die Codes noch hinterher. Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt. Und noch eine Bemerkung zum Schluss: ich wollte hier gar nichts "optimieren", bin nur gebeten worden, einen Unterschied zu ermitteln zwischen PHP-Arrays und klassischen statischen Arrays. Da es die in PHP eigentlich gar nicht offen zugänglich gibt für den Anwendungsprogrammierer, muss ich mir eben eine Krücke ausdenken. 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. Alldings word meine Ausgabevarable mit `$out .= ...` ja auch in allen Fällen in nahezu Nullzeit gefüllt. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, > > Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht. > > Dann optimierst du möglicherweise an der falschen Stelle. Es gibt eine Faustregel die bessagt, dass ein Programm geschätzte 90% der Laufzeit in 10% des Codes verbringt. Es hilft also in der Regel recht wenig auf Verdacht zu optimieren, weil man dann mit hoher Wahrscheinlichkeit nur sehr kleine Potenziale ausschöpfen kann. Es ist viel effektiver auf Sicht zu fahren, und erstmal die Engpässe zu ermitteln und sich eine Übersicht der Lage zu verschaffen. Dafür gibt es extra Werkzeuge. xdebug hat bspw. auch einen Profiler integriert, damit kann man eine detaillierte Aufzeichnung des Laufzeitverhaltens erstellen. Betrachten und auswerten kann man die Aufzeichnungen dann mit KCachegrind. Wenn du dann den Engpass gefunden hast, dann weißt du auch, wo hohes Optimierungspotenzial liegt und kannst dann gezielt optimieren. Vielen Dank für deine Unterstützung. Die verantwortliche Stelle habd ich schon gefunden und dort auch eingegriffen. Es liegt hauptsächlich am Schreibzugriff - "copy-on-write". Danke für die Erinnerungsstütze bezüglich der Bezeichnung. > > Es scheint mit hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen. > > Meinst du copy-on-write? Das ist eine Perforamnce-Optimierung, sie macht Code in der eher Regel schneller als langsamer. Das stimmt, solange man eben **nicht** schreibend (ändernd) zugreift. In meinem Versuchsbeispiel sieht man das auch ganz deutlich. Der Aufbau der Grafikseite aus denselben z. Zt. ca. 60.000 Datensätzen geht in Nullkommanix. 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) Die alte Methode hat den Vorteil, dass die Datei nicht sortiert sein muss. Die neue arbeitet mit klassischem Gruppenwechsel. Beide laden zunächst die Datei mit `file()`. Das funktioniert überraschenderweise allerdings auch in Nullkommanix. Die grafischen Anzeigen nutzten auch `file()`. Wenn ich mehr getestet habe, schiebe ich die Codes noch hinterher. Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt. Und noch eine Bemerkung zum Schluss: ich wollte hier gar nichts "optimieren", bin nur gebeten worden, einen Unterschied zu ermitteln zwischen PHP-Arrays und klassischen statischen Arrays. Da es die in PHP eigentlich gar nicht offen zugänglich gibt für den Anwendungsprogrammierer, muss ich mir eben eine Krücke ausdenken. 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. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.