Geschwindigkeit bei Verwenden von require/include

Hallöchen,

ich habe eine Frage bezüglich zur Geschwindigkeit beim Einbinden mittels
require oder include.

Ich habe bisher in keinem Forum eine (befriedigende) Antwort auf diese
Frage erhalten, deshalb denke ich, dass sie in das Profi-Forum gehört.

Ich habe momentan ein ziemlich großes Projekt am laufen, in dem ich
viele Module einbinde. Nun habe ich aber festgestellt, dass das Einbinden
einer neuen Datei mittels include/require extrem lange dauert.

Ich habe dann vergleichsweise ein Pear-Modul eingebunden, da waren die
Zeitunterschiede zum Einbinden meiner Module extrem hoch.

Hier ein Bsp. (Zeitunterschiede in <Sekunden>.<Microsekunden>):

//Pear-Module einbinden
require_once("PEAR.php");
require_once("Config.php");
//Zeit zum Einbinden: 0.00739789009094
 
//Eigene Module einbinden
require_once("wt_defs.inc.php");
//Zeit zum Einbinden: 0.105256080627 

Kann mir jemand erklären, woran so etwas liegt? An meinem Projekt sind
18 Module beteiligt, d.h. er braucht zum Einbinden der ganzen Dateien
alleine schon 2 Sekunden, die Rechenzeit zum Ausgeben der Seite noch
nicht mitberechnet.

Ich könnte jetzt natürlich alle Quelltexte in ein Modul packen, aber da
würde die Wiederverwendbarkeit und Übersichtlichkeit echt drunter
leiden...

Wäre nett, wenn mir jemand weiterhelfen könnte.

Bin gespannt, ob es hier zu einer verwertbaren Diskussion kommt

[Forumsgast]

Ich gehe nicht davon aus, dass das Einbinden diese Zeitspanne verursacht. Sowohl include, als auch der Zend Parser arbeiten sehr effizient. Hast du in deinen Modulen ausschliesslich Funktionen und Klassen definiert oder machst du dort auch etwas?

Teils teils.

Ich habe den Test selbstverständlich in vielen verschiedenen Varianten
gemacht. Sowohl mit includes, die nur Funktionen und/oder Klassen
enthalten, als auch Module, die direkt ausgeführten Code enthalten,
Module, die zeitfressende Funktionen wie is_dir() oder
file_exists() enthalten.
Das erstaunliche ist, die Zeit zum Einbinden ist immer gleich, sie pendelt
zwischen 0,1 und 0,2 Sekunden (meine Dateien sind auch fast alle gleich
groß).
Das merkwürdige ist ja auch, dass das Einbinden der PEAR-Module nur
einen Bruchteil der Zeit braucht, diese Dateien aber viel größer sind als
meine, aber sowohl Funktionen/Klassen als auch sofort auszuführenden
Code enthalten.

Ich habe jetzt noch ein wenig mehr rumprobiert und zusätzliche
Feststellung gemacht:

Ich include die wt_system.inc.php in meiner index.php-Datei

<?php
require_once("modules/wt_system.inc.php");
?>

In diesem Modul befinden sich alle Aufrufe meiner Module, um mein Script
zu "booten". Der Aufruf dauert ca. 2 Sekunden.

Nun habe ich testweise die Datei wt_system.inc.php direkt aus dem
Browser aufgerufen (also ohne das die index.php das Modul erst aufruft)
und nun dauert der Aufruf nur noch 1/100 der Zeit (0.0223000049591
Sekunden).

Jetzt bin ich völlig verwirrt... daraufhin habe ich auch noch das Einbinden
einzelner Module gecheckt beim direkten Aufruf der wt_system.inc.php -
während das Einbinden der PEAR-Module immer noch die gleiche Zeit in
Anspruch nimmt, brauchen meine eigenen Module jetzt ca. genau so lange
wie die PEAR-Module.

[Forumsgast]

Hmm... also ich habe es bei meinen Skripten mal gemacht und mit einem schnuckeligen kleinen Skript den größten Teil meiner includes aufgelöst und durch den Dateiinhalt der entsprechenden Datei ersetzt. Dies hat in etwa 10% bessere Perfomance gebracht.

Es liegt also nicht am lesen der Dateien selbst.

Das Problem wird wohl sein, dass bei include() nicht nur die Datei eingebunden, sondern gleichzeitig auch deren Quelltext geparst wird.

Logisch: bei PEAR geht das fix, weil das ganze Zeug garantiert vorcompiliert im Cache liegt.

Schau dir mal die Dateien an, die dort geladen werden. Wenn die aktiv irgendwas machen (also nicht nur Definitionen von Klassen/Funktionen/Konstanten enthalten). Dann wird dieser Code automatisch beim Aufruf von include ausgeführt.

PS: Schau mal nach den preg_* Funktionen. Reguläre Ausdrücke sind je nachdem wie sie formuliert sind echte Perfomance-Fresser -> vor allem innerhalb von Schleifen. Allein ein einziger Modifikator "/i" kann dir in ein einer Schleife mit ein paar Hundert Durchläufen bei hinreichend langen Texten locker 10 ms Verlust bringen.

Wir haben bei uns in der Firma schon mal die Laufzeit eines Perl-Skripts zur Textkonvertierung (Batch-Programm) von 3 Stunden auf 45 Minuten reduziert, nur durch Optimierung von regulären Ausdrücken (allerdings: bei etwa 200MB Eingabedaten)

[Forumsgast]

Logisch: bei PEAR geht das fix, weil das ganze Zeug garantiert vorcompiliert im Cache liegt.

Wie meinst du das?

[Forumsgast]

Dass es schneller ist, ist klar, weil beim direkten Reinkopieren ins Basis-Script der Overhead fürs Parsen wegfällt bzw. ganz zu Beginn gemacht wird. Beim Include wird er später gemacht. Du kannst die Werte ob mit oder ohne Include nie vergleichen, du kannst dann nur die Gesamt-Script-Laufzeit messen und die sollte, ob mir oder ohne Include nahezu gleich bleiben.

Hmm, die Antworten klingen einleuchtend. Dann muss ich die lange Laufzeit wohl in Kauf nehmen... es wäre natürlich edel, wenn man ein php-Modul vorcompilieren könnte (es wäre dann zwar kein wirkliches Skript mehr ), so dass es wie bei den Pear-Modulen eine geringe Laufzeit gibt.

Ist sowas möglich, eventuell auch auf Shared-Servern

Ich finde nämlich, eine Laufzeit von 2 Sekunden nur zum Laden von Einstellungen und Klassen/Funktionen ist ein wenig viel...

Zuerst dachte ich immer, die lange Laufzeit hätte mit der Flexy-Template Klasse zu tun, aber die scheint sehr schnell zu sein Schade eigentlich, dann hätte ich einfach eine anderes Template verwendet...

[Forumsgast]

Hmm, die Antworten klingen einleuchtend.

Dass muss nichts heissen.

Dann muss ich die lange Laufzeit wohl in Kauf nehmen... es wäre natürlich edel, wenn man ein php-Modul vorcompilieren könnte

In diesem Falle wohl v.a. unnötig, denn das kompilieren geht relativ schnell.
Die Geschwindigkeit beim einbinden von PEAR-Dateien ist nichts besonderes, sondern der Normalzustand. Um herauszufinden, was bei deinen Dateien anders ist, bräuchtest Du einen Hellseher und keinen Profi, oder Du siehst selbst nach.

Soviel gibt meine Glaskugel übrigens her: Keine PHP-Datei wird eine Sekunde kompiliert. Die Dateien bestehen wohl nicht nur aus Funktions/Klassendefinitionen, sondern führen noch irgendwas aus.

[Forumsgast]

Dann muss ich die lange Laufzeit wohl in Kauf nehmen...

Du kannst unmöglich hinnehmen, dass dein PHP 2 Sekunden braucht, nur um sich ein paar Klassendefinitionen zu holen! Ich würde dem Problem in jedem Fall mal ganz tief auf den Grund gehen.

Wie sind denn die Zeiten beim Include einer leeren Datei? Wo liegen die einzubindenden Daten? ...

Basti

Hmm, ja, stimmt... ich bin seitdem auch total genervt und hab nicht mehr weiter an dem Projekt gearbeitet... niemand wird es nutzen wollen, wenn die Laufzeit dafür so lang ist...

Ich werde mich als nächstes dem Vorschlag von Basti widmen und danach prüfen, ob die Zeiten auf meinem SharedServer auch so lange dauern. Vielleicht ist meine PHP-Version Buggy oder die php.ini falsch konfiguriert oder was (wobei mir da nicht einfällt, was falsch konfiguriert sein könnte).

Wobei ich auch gerade festgestellt habe, dass das die Ausgabe meiner Daten (inklusive deren Berechnung) gerade mal 0,3 Sekunden dauert... wenigstens etwas...

Soooo... ich habe das ganze nochmals mit leeren Dateien auf meinem Server getestet... gleiches Ergebnis.

Dann habe ich mir die Mühe gemacht, den ganzen Apparat auf meinen SharedHost zu schaufeln und voilà: Das Laden eines Moduls dauert jetzt ganze 0.00054216384887695 Sekunden.
Das Einbinden meines kompletten Pakets 0.053107976913452 Sekunden.

Ich denke, dass ist eine annehmbare Zeitspanne. Ich bin jetzt natürlich immer noch am Überlegen, weshalb das bei mir so lange dauert. Könnte natürlich am Betriebssystem liegen (SharedServer Linux/Unix, mein Laptop Windows XP/Home ).
Wäre ja an sich ne traurige Geschichte (Win suxx...). Nun, aber jetzt bin ich wieder motiviert, das Projekt zu erweitern...

Wen es interessiert: Es handelt sich dabei um ein universelles WebTempate (so habe ich es getauft), dass den Komfort von Templates mit einer Menge nützlicher Tools verbindet (Automatische Datenbankanbindung, Session-Verwaltung, Mehrsprachigkeit, Multi-Templates, vollautomatisches Erzeugen der kompletten Header-Daten über XML und Einstellungsdateien auf XML-Basis).

[Forumsgast]

Defrag? Swap? Nur so als Ansatzpunkt, weshalb es bei dir lokal bischen länger dauert.