viele kleine vs wenige große Dateien

[CC84]

Ich plane gerade ein größeres Projekt und wollte an der Stelle mal fragen, was aus Performancesicht sinnvoller ist.

Lieber wenige Große Dateien nutzen, die dann bei jedem Seitenaufruf komplett geparst werden müssen, auch wenn man nur einen kleinen Teil davon braucht, das dürfte die CPU schön wärmen. Oder lieber viele kleine Dateien, womit die IO Last steigt, man aber möglichst wenig unnötige Dateien parst.

Gibt es da eine pauschale Antwort?

[nohfreak]

Also wenn du alles in eine große Datei packst und die verschiedenen Funktionen alle in IF-Blöcken drin hast, dann werden die ja garnicht alle geparset.

In einem IF Block wird der Inhalt meiens Wissens nur geparst, wenn die Bedingung erfüllt ist.

Bin aber selber noch am Anfang meiner Coding-Karriere, also verlass dich lieber nich drauf

[onemorenerd]

Ja, verlass dich nicht drauf. Denn es ist falsch. Geparst wird immer alles!
Das kann auch leicht bewiesen werden:

<?php if (false) { syntax error } ?>

Ich wette, dass deine Seite so klein ist, dass du es dir locker leisten kannst, deinen Code so zu verteilen, dass er sich vor allem leicht warten läßt. Zusammengehörenden Code und wiederverwendete Blöcke in Includes auslagern, die Struktur des Scripts aber möglichst komplett in einer Datei halten.

[CC84]

das halte ich für eine SEHR gewagte These. Sie werden nicht ausgeführt, aber geparsed bzw. compiled (bin mir gerade nicht sicher, wie sich das bei Scriptsprachen nennt) werden sie recht sicher. Spätestens wenn man Klassen hat, ist zur Compilezeit ja nicht bekannt, ob diese oder jene Codestelle später auch ausgeführt wird.

Zum zweiten Kommentar: Ich schreibe ein bestehendes Projekt neu. Quellcode aktuell fast 300kb. Es ist also schon etwas mehr.

[ModestLife]

Das Backend macht normalerweise bei der Performance gerade mal 10 bis 20 Prozent aus. Der Rest ist Frontend (Bilder, Scripts, Stylesheets, swf's, etc.).

Also lieber erst mal dort optimieren.

[CC84]

noch so eine gewagte These.

erstens benutze ich kein SWF und aktuell kein JS, aber selbst wenn, das läuft alles auf dem Client, kann mir also ziemlich egal sein.

Insgesamt weiß ich aber auch nicht, wo die von dir genanntne Files überhaubt belastung machen. Ok IO Zugriffe, aber der Server CPU sollte das völlig egal sein.

Diese Sachen fallen beim Traffic ins Gewicht, das mir aber gerade nicht die Sorgen macht.

[onemorenerd]

ModestLife meint scheinbar die gefühlte Performance der Webseite. Die wird, da hat er Recht, nicht allein und meißt auch nicht maßgeblich von der PHP-Ausführungszeit bestimmt.
Wenn du die Anzahl der Requests halbierst, die der Browser für eine Seite machen muß, wird die Seite so viel schneller wirken, wie du es mit PHP-Optimierung kaum erreichen kannst.

Natürlich alles irgendwie abstrakt ... man muß es schon auf die jeweilige Applikation anpassen.

[ModestLife]

Original geschrieben von onemorenerd
ModestLife meint scheinbar die gefühlte Performance der Webseite. Die wird, da hat er Recht, nicht allein und meißt auch nicht maßgeblich von der PHP-Ausführungszeit bestimmt.
Wenn du die Anzahl der Requests halbierst, die der Browser für eine Seite machen muß, wird die Seite so viel schneller wirken, wie du es mit PHP-Optimierung kaum erreichen kannst.

Natürlich alles irgendwie abstrakt ... man muß es schon auf die jeweilige Applikation anpassen.

Richtig. Wenn für 50 Bilder ein HTTP-Request gemacht werden muss, hat das ziemlich grosse Einwirkung in der Performance einer Website.

Also Beispiel kann ich hier die showpost.php nehmen (mit leerem Cache):
showpost.php: 12kb 16ms
Gesamt: 51kb 13.49s

Dies mag natürlich variieren, von Aufruf zu Aufruf. Die Grundaussage sollte aber doch durchdringen.

[3DMax]

ich würde allein schon wegen der übersicht die applikation in viele kleine dateien aufteilen. pro klasse / interface eine datei, das hat auch den vorteil, dass man dynamisch, bei bedarf, mit der autoload-funktionalität inkludieren kann.

die plattenzugriffe auf die dateien sollte eigentlich das os durch caching optimieren bzw. minimieren. darüber würde ich mir keine gedanken machen.

[unset]

Original geschrieben von 3DMax
ich würde allein schon wegen der übersicht die applikation in viele kleine dateien aufteilen. pro klasse / interface eine datei, das hat auch den vorteil, dass man dynamisch, bei bedarf, mit der autoload-funktionalität inkludieren kann.

Sehe ich ähnlich. Ich teile Code in Sinnvolle Abschnitte auf und lese ihn bei Bedarf ein. Autoloading ist da wie schon erwähnt nicht nur komfortabel sondern auch Ressourcenschonend.

[CC84]

Original geschrieben von onemorenerd
ModestLife meint scheinbar die gefühlte Performance der Webseite. Die wird, da hat er Recht, nicht allein und meißt auch nicht maßgeblich von der PHP-Ausführungszeit bestimmt.
Wenn du die Anzahl der Requests halbierst, die der Browser für eine Seite machen muß, wird die Seite so viel schneller wirken, wie du es mit PHP-Optimierung kaum erreichen kannst.

Natürlich alles irgendwie abstrakt ... man muß es schon auf die jeweilige Applikation anpassen.

Das ist ja nett, was er meint. Aber ich habe vor einigen Jahren mal nen Server bei 80% Last gehabt, weil PHP Scripte einfach schlecht waren. Und genau sowas will ich verhindern.

[unset]

Da muss man sich aber echt anstregend, und falls du dich auf die Aussage von top beziehst: Das ist kein Prozentwert.