Zugriffe auf das Dateisystem bei __autoload

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

  • Zugriffe auf das Dateisystem bei __autoload

    Hallo,

    in meinem autoloader suche ich in einer Schleife in 4 verschiedenen Ordner ob die gesuchte Datei in einem der Ordner vorhanden ist.
    Das passiert natürlich zimelich oft, da alle Klassen meines Projekts so geladen werden.

    Mir wurde letztens erzählt, dass Zugriffe auf das Dateisystem über php eher langsam sind.
    Natürlich merkt man das nicht unbedingt, aber wenn demnächst wirklich last über das Projekt läuft, was dann!?

    Hier mal zur Veranschaulichung mein Code in der __autoload Funktion:

    PHP-Code:
    foreach($dirs as $pattern => $path){

                if(
    file_exists($path $filepattern)){
                    require_once(
    $path $filepattern);
                    break;
                }

    Gibt es da in der Hinsicht eine noch intelligentere Lösung?
    Eine Textdatei für die absoluten Pfade halte ich auch nicht unbedingt für eine optimale Lösung, aber sonst fällt mir im moment auch nichts besseres ein.
    Habt ihr evtl. bessere Lösungen parat?

    Vielen Dank

  • #2
    Testsystem von Livesystem unterscheiden, und die Prüfung nicht auf "deployten" Systemen machen. Wenn die Klasse nicht gefunden wird, bekommst du auch so einen Fehler – wenn die paar Millisekunden wirklich so wichtig sind!
    Zuletzt geändert von unset; 24.09.2010, 14:51.
    [FONT="Helvetica"]twitter.com/unset[/FONT]

    Shitstorm Podcast – Wöchentliches Auskotzen

    Kommentar


    • #3
      Zitat von unset Beitrag anzeigen
      Testsystem von Livesystem unterscheiden, und die Prüfung auf "deployten" Systemen machen. Wenn die Klasse nicht gefunden wird, bekommst du auch so einen Fehler – wenn die paar Millisekunden wirklich so wichtig sind!
      Bitte????^^

      Kommentar


      • #4
        Habt ihr evtl. bessere Lösungen parat?
        Natürlich!!
        1. halte dich an das Zend/Pear Benennungsschema für Klassen und Dateien.
        2. Verwende SPL Autoload statt __autoload

        Weil:
        Dann wird deine Klasse von deinem Autoloader immer sofort beim ersten Zugriff gefunden. Und es kommt beim einbinden von anderen FWs nicht zu Problemen
        Wir werden alle sterben

        Kommentar


        • #5
          Zitat von dakingno1 Beitrag anzeigen
          Bitte????^^
          Du wirst das doch wegen einem Wort wohl trotzdem noch verstanden haben …
          [FONT="Helvetica"]twitter.com/unset[/FONT]

          Shitstorm Podcast – Wöchentliches Auskotzen

          Kommentar


          • #6
            Zitat von combie Beitrag anzeigen
            Natürlich!!
            1. halte dich an das Zend/Pear Benennungsschema für Klassen und Dateien.
            2. Verwende SPL Autoload statt __autoload

            Weil:
            Dann wird deine Klasse von deinem Autoloader immer sofort beim ersten Zugriff gefunden. Und es kommt beim einbinden von anderen FWs nicht zu Problemen
            Also SPL Autolaod sagt mir auf anhieb nix, aber wenn ich nach dem Tutorial urteile kann, dann passiert da auch nichts anderes als in meinem Beispiel?

            Kommentar


            • #7
              Zitat von dakingno1 Beitrag anzeigen
              in meinem autoloader suche ich in einer Schleife in 4 verschiedenen Ordner ob die gesuchte Datei in einem der Ordner vorhanden ist.
              Das Problem ist, dass du nicht aus dem Klassennamen ableitest wo die Datei liegt. Eine Lösung wurde dir bereits genannt: Halte dich ans PEAR/Zend-Schema!

              Kommentar


              • #8
                Zitat von onemorenerd Beitrag anzeigen
                Das Problem ist, dass du nicht aus dem Klassennamen ableitest wo die Datei liegt. Eine Lösung wurde dir bereits genannt: Halte dich ans PEAR/Zend-Schema!
                Das ist eigentlich eine gute Lösung, korrekt.
                Aber da das Projekt bereits steht, müsste ich nun alle Klassennamen, deren Dekalration und dann noch deren Aufrufe anpassen, das wäre den Aufwand dann auch nicht wert denke ich.

                Vielen Dank trotzdem!

                Kommentar


                • #9
                  Um wie viele Klassen handelt es sich, wie viele werden im Schnitt pro Request geladen und wie viel Zeit geht dafür drauf?
                  Erst wenn du diese Fakten kennst (gemessen, nicht geraten!), kannst du sagen ob und was überhaupt optimiert werden muss.

                  Sollte es aus technischer Sicht wirklich notwendig sein, sprechen sicherlich betriebswirtschaftliche Gründe gegen ein umfassendes Refactoring. Schließlich gibt es billige Alternativen: Opcode Caching, Cloud Computing oder einfach mehr Hardware kaufen.

                  Die Welt ist groß, das Leben ist kurz – mach dir keine Gedanken, die Last läuft an deinem Projekt vermutlich vorbei. ;-)

                  Kommentar


                  • #10
                    und wie viel Zeit geht dafür drauf?
                    5 Minuten pro Klasse.
                    (geschätzt)

                    Es gibt nur 3 Wege, welche zum Erfolg führen:
                    1. Problem analysieren, Lösung erarbeiten, durchsetzen
                    2. Abschauen! Schauen, wie es die andern manchen und genau so machen
                    3. Aus Erfahrung lernen, auch unter Schmerzen

                    Alle anderen Wege führen nicht zum Erfolg.
                    Auch der nicht, wo man gegen besseres Wissen, auf dem falschen Weg weiter geht.

                    Natürlich mag es gute Gründe gegen die Umstellung geben...
                    Aber es gibt auch gute Gründe dafür:
                    1. Je eher die Umstellung, desto einfacher ist sie noch
                    2. Die eigene Klassensammlung wird kombinierbar mit (allen) anderen modernen Klassensammlungen
                    3. Der Code wird ein gutes Stück selbst dokumentierend.
                    Wir werden alle sterben

                    Kommentar


                    • #11
                      Zitat von combie Beitrag anzeigen
                      1. Je eher die Umstellung, desto einfacher ist sie noch
                      Das ist nur dann ein Grund, wenn das Projekt noch weiter entwickelt wird. Bei den meisten Projekten werden ab einem gewissen Punkt aber nur noch kleine Änderungen gemacht und Bugs gefixt. Das geht auch ohne Umstellung schnell. Durch eine Umstellung (die ja erstmal viel Zeit kostet) gewinnt man kaum Zeit zurück.
                      2. Die eigene Klassensammlung wird kombinierbar mit (allen) anderen modernen Klassensammlungen
                      Dann sollte man lieber einen Branch der Klassensammlung anlegen und diesen umstellen. Das Projekt, welches die Sammlung bereits benutzt, muss dazu nicht geändert werden.
                      3. Der Code wird ein gutes Stück selbst dokumentierend.
                      Das schlägt in die selbe Kerbe wie 1 und 2. Gut dokumentierter Code spart Geld, wenn man mit ihm arbeitet, nicht an ihm.

                      Kommentar

                      Lädt...
                      X