2009-09-02T09:13:05 Taulmarill

Ich denke es geht hier um die gesamte Laufzeit des Interpreters und nicht die des Programms selbst. Bei CGI macht das schon Sinn, sich um solche Sachen Gedanken zu machen.

Auch bei CGI würde ich nicht wirklich drauf achten ob Dateien aufgesplittet sind, weil das verglichen zu anderen aufgaben wohl absolut keine auswirkung haben wird.

Ansonsten würde ich generell kein CGI heutzutage mehr empfehlen. Da es per Default langsam ist dadurch das es immer wieder neu Compiliert.

Okay jetzt wirst du mir sagen das es für sehr kleine sachen wo selten jemand drauf schaut noch nutzbar ist? Wenn das der Fall ist spricht ebenfalls nichts gegen das aufsplitten in Dateien, da es einfach keine große Performance fressen wird, und wenn mal jemand drauf geht es egal ist wenn der Request 1ms länger dauert (wenn es überhaupt 1ms sind durchs Datei aufsplitten).

Ansonsten muss man halt immer die Sachen im Verhältnis sehen. Es bringt nichts sinnlose Stellen zu Optimieren die auf die allgemeine ausführungszeit fast keine auswirkung haben. Und die mammutzeit die man eben bei einem webseitenrequest hat werden eher im auslesen der Daten von einer Datenbank sein, oder das ausführen des Templates sein etc.

Liegt das Hauptproblem daran das Programmcode in mehrere Dateien aufgesplittet ist, wäre dann die Lösung CGI nicht mehr zu nutzen wodurch es eben nicht mehr bei jedem aufruf geladen wird. Obwohl ich mir schwer vorstellen kann das dies jemals ein Performance Problem sein wird.

Ein anderes problem kann sein das das laden der Module lange dauert. Hier ist aber auch das Problem CGI, weil es ja eben nicht persitent ist, sondern immer wieder neu lädt. Oder ein Problem von Perl das es die Compilierte Form nie abspeichert (je nachdem wie man es sieht). Auch hier wäre dann aber die Lösung eben kein CGI mehr zu nutzen. Oder krücken wie "AutoLoader" zu nutzen.

EDIT: zwei wörter nur ausgetauscht.
Last edited: 2009-09-02 11:38:32 +0200 (CEST)