Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] __autoload() effizient verwenden

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Oder am Beispiel von Doctrine's Compiler kann man auch eine komplette Bibliothek oder Teile davon in einer Datei zusammenfassen, geht dann etwas zu lassten des speicherverbrauchs
    Hat zwar nichts mit demAutloading-Thema zu tun, aber zum Compiling von Doctrine: Das habe ich mal testweise gemacht (Allerdings ohne PAC o. ä.). Danach lag der Speicherverbrauch des Skripts bei 13 MB statt 4 MB - allein für Doctrine und 2 Active-Records..

    Kommentar


    • #17
      Zitat von xm22 Beitrag anzeigen
      Hat zwar nichts mit demAutloading-Thema zu tun, aber zum Compiling von Doctrine: Das habe ich mal testweise gemacht (Allerdings ohne PAC o. ä.). Danach lag der Speicherverbrauch des Skripts bei 13 MB statt 4 MB - allein für Doctrine und 2 Active-Records..
      // edit:
      // mit PAC meintest du wohl APC bzw. allgemein Bytecode-Caches oder ? Konnte damit nämlich nichts anfangen

      Das klingt für mich auch nach Werten ohne Bytecode-Cache oder dem ersten aufruf wo die Datei noch nicht gecacht war.

      Ohne Bytecode-Cache hat man bei PHP logischerweise immer einen viel höheren Speicherverbrauch, weil ja jedes mal die komplette datei gelesen werden muss, geparst werden muss und dann in Bytecode umgesetzt werden muss bevor er schlussendlich ausgeführt wird. Allein die kompilierte Version von Doctrine hat eine Dateigröße von ~ 850kb.

      Bei ner applikation mit ZF, Doctrine und weiteren Bibliotheken, kommen da ohne Bytecode-cache schnell alleine für den compilieraufwand und soweiter overhead von 10 - 20mb hinzu, was mit einer der gründe ist warum php ohne bytecode-cache ein gutes stück resourcenhungriger ist.

      Der Compiler von Doctrine bzw. allgemein das packen von vielen Klassen in eine Datei macht also nur dann Sinn wenn man einen Bytecode-Cache nutzt und eh einen großen Teil der Klassen die in dem Paket sind dann auch nutzt und sie daher auch hätten geladen werden müssen.

      Doctrine 1.X besteht aus mehr als 300 Klassen und Interfaces, wenn man das komplettpaket nimmt (beim compiler kann man das noch etwas reduzieren, wenn man nur den db-adapter mitreinpackt den man auch nutzen will).

      Hab gerade mal hier lokal mit php 5.3.2 mit und ohne APC das mit dem Doctrine-Compiler ausprobiert.

      Wenn ich nur die kompilierte Doctrine-Datei include erhöht das den speicherverbrauch beim ersten mal um 10,3MB, sobald die Datei im Bytecode-Cache von APC ist sind es nur noch 3,4MB.

      Ohne APC sind es dann immer ca 10,2 MB mehr.

      Die dauer für den include:
      apc beim ersten include: 0.21s (10,3MB)
      apc bei weiteren includes: 0.03s (3,4MB)
      ohne apc: 0.16s (10,2MB)

      Hier sieht man recht schön was Bytecode-Cachesbringen können, sowohl für die performance bei vielen Dateien, also auch für den Speicherverbrauch im gesamten und warum man sie wenn man die möglichkeit hat (v/root/managed server) definitiv nutzen sollte.
      robo47.net - Blog, Codeschnipsel und mehr
      | Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

      Kommentar


      • #18
        Ich habe mir einen, wie ich finde ziemlich coolen Autoloader gebastelt.
        Ich erstelle mir eine Datei, die mir einfach ein Array zurückgibt. In diesem Array stehen als
        Key-Value Werte Klassenname und Dateipfad (bps.: array('Bootstrap' => 'D:/xampp/htdocs/mvc/library/psfw/Bootstrap.php',...))
        So dann binde diese Datei einmal ein und überprüfe dann im __autoload() über isset() ob diese Klasse gesetzt ist.

        Das hat den Vorteil, dass der autoloader weniger Dateizugriffe auf die Platte macht, denn diese Funktion, läuft über den include_path und schaut der Reihe nach ob so eine Klasse mit diesem Pfad eingebunden werden kann. Dies bedeutet, dass wenn erst an 5ter Stelle im include_path deine datei gefunden werden würde, macht das 5 Dateizugriffe statt einem.

        Man mus quasi einmal ein rekursives Skript ausführen, dass alle Klassen in eine array schreibt und dieses dann in einer Datei auf der Platte speichert. Und sich dann natürlich freuen

        bei Bedarf kann ich das ganze auch mit Code näher erläutern.
        "My software never has bugs, it just develops random features."
        "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

        Kommentar


        • #19
          Hallo zusammen,

          schöne Debatte. Rein performancetechnisch und designtechnisch ist diese Möglichkeit sicher für den Praxiseinsastz zu vernachlässigen, aber ist das Setzen des Includepath nicht eine Möglichkeit, Dateizugriffe von PHP selbst verwalten zu lassen, statt unnötigerweise Code dafür zu schreiben?

          Also quasi einmal das Hauptverzeichnis mit den Klassen rekursiv in den include_path überführen, statt alle Klassen in einem Array zu halten.

          PHP-Code:
          // Beispielhaft, nicht elegant
          set_include_path(ini_get('include_path').':'.implode(':'$aLibPaths)); 
          Tutorials zum Thema Technik:
          https://pilabor.com
          https://www.fynder.de

          Kommentar


          • #20
            Zitat von hpf Beitrag anzeigen
            Du musst ja nicht bei jedem Scriptaufruf alle Verzeichniss scannen, sondern nur einmalig oder wenn neue Dateien hinzugekommen sind. Beim Scannen kannst du dir ein Array mit der Zuordnung Klassenname => Include-Datei erstellen und dieses dann serialisieren. Die Autoload-Funktion kann dieses Array dann wieder deserialisieren und hat so die Zuordnung.
            So mache ich es bei meinen Applikationen auch. du erstellst eine Datei, in der alle Klassen bereits mit ihren Name und Pfaden "registriert" sind, dann kann kannst mit einfachen Array-Funktionen schauen wo diese datei liegt

            in php5.3 könnte man sowas in der Art realisieren
            PHP-Code:
            function __autoload($class) {
                static 
            $loadedClasses = include('registeredClasses.php');
                ....

            Dabei wird die "registeredClasses.php" auch nur beim ersten Mal eingebunden.


            OT:
            ich habe das gefühl, dass es immo kaum Provider gibt, die PHP5.3 anbieten, weils wohl ncoh net sauber läuft.
            Weiß jemand was genaueres dazu?
            "My software never has bugs, it just develops random features."
            "Real programmers don't comment. If it was hard to write, it should be hard to understand!"

            Kommentar


            • #21
              ich habe mal darüber nachgedacht die klassen die ein Controller benötigt in Pakete dynamisch zusammen zu führen und zu Cachen, somit könnte die io Arbeit auf ein Dateisystem auf ein minimum reduziert werden.

              Kommentar


              • #22
                Generell ist die Idee nicht schlecht, wobei natürlich auch Vorteile wegfallen:

                - unbenutzte Klassen werden nicht geladen
                - (damit kleine Dateigrößen)
                - Klassendefinitionen können überschrieben werden (siehe oben)
                --

                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                --

                Kommentar


                • #23
                  generell liegt dies ja daran, wie schlau das System die Controller packt. zudem ist es ja so, dass innerhalb eines Controllers ähnliche aufgaben abgearbeitet werden, diese benötigen idr. einen ähnlichen Zugriff auf die Datenschicht.

                  die Problematik mit den Klassendefinitionen seh ich irgendwie nicht

                  Kommentar


                  • #24
                    generell liegt dies ja daran, wie schlau das System die Controller packt. zudem ist es ja so, dass innerhalb eines Controllers ähnliche aufgaben abgearbeitet werden, diese benötigen idr. einen ähnlichen Zugriff auf die Datenschicht.
                    Kann mit dieser Antwort irgendwie nichts anfangen. Bezug?
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar

                    Lädt...
                    X