• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

Compiler für ZF

KingCrunch

New member
Ich hatte so einen spontanen Einfall, der zugegeben etwas von Doctrine geklaut ist, und möchte mal eure Meinung, Anregungen und konstruktive Kritik hören.

Der Compiler von Doctrine fasst quasi das komplette Framework in einer einzigen Datei zusammen. Damit wäre auch schon das wichtigste gesagt :D Angeblich, laut Doctrine-Manual, soll das durchaus spürbaren Performance-Gewinn bringen, weil weniger Plattenzugriffe. Sowas in der Art wäre auch für das Zend Framework denkbar, wobei ich da eher Komponenten-basiert ansetzen würde, anstatt das gesamte Framework, was ja immerhin geschlagene 800 Dateien (grob) bereit stellt.
Exemplarisch:
PHP:
// We want to compile Translate
// especially this means all files in Zend/Translate/*
$compiler = new Bla_Compiler_Component('Translate');

// We want only specified adapters to be compiled
$compiler->setOptions (array ('adapter'=>array('gettext','xml')));

// strip comments and whitespace?
// An IDE, which uses docblocks, isnt able to retrieve the required information
// if comments are missing.
$compiler->stripComments (true);

// Compile and save at ..
$compiler->compile ('path/to/Zend_Translate.compiled.php');
Problematisch sind vorallen dynamische includes ausserhalb des eigenen Packages und Datendateien (Zend_Locale hat da meines Wissens einige von), die nichts in einer php-Datei zu suchen haben. Sowas müsste man dann von Hand rausbasteln, wenn man nicht jedes mal das komplette Framework einzeln noch daneben stehen haben möchte.

Eigentlich wars das auch schon :)

Achja, was mir noch an Problemen einfällt:
1. Das Ding beißt sich mit bestehenden Applikationen, die mit selbst die Dateien includen
2. Im Falle eines autoloads erkennt Zend_Loader nicht, dass es sowas wie compilierte Dateien gibt.
 
Zuletzt bearbeitet:

DennisBecker

Super-Moderator
Hört sich stark nach PHAR und ähnliche Ansätze an. Wobei dese ganz klar sagen, dass nur das "deployement" vereinfacht wird, weil man nur eine Datei auf den Webserver laden müsste. Wirkliche Vorteile erkenne ich daraus nicht.

Um mehr Performance rauszuholen würde ich den eAccelerator installieren, da dies dann auch nicht-ZF-Dateien betrifft.
 

KingCrunch

New member
Hört sich stark nach PHAR und ähnliche Ansätze an.
"Ähnliche Ansätze" ja, "Phar" nein ;) Phar ist ein Archiv, sprich die Dateien bleiben einzeln, aber eben im Archiv.
Wobei dese ganz klar sagen, dass nur das "deployement" vereinfacht wird, weil man nur eine Datei auf den Webserver laden müsste. Wirkliche Vorteile erkenne ich daraus nicht.
Weniger Dateizugriffe. Steht da doch :p
Um mehr Performance rauszuholen würde ich den eAccelerator installieren, da dies dann auch nicht-ZF-Dateien betrifft.
A schließt B nicht aus :p
 

thomas

Moderator
Statt nur Komponentenbasierend könnte man doch auswählen WELCHE Komponente integriert werden soll... damit hättest Du beide Ansätze drin. Wird nix angegeben ist es automatisch alles inklusive :)
 

KingCrunch

New member
Statt nur Komponentenbasierend könnte man doch auswählen WELCHE Komponente integriert werden soll... damit hättest Du beide Ansätze drin. Wird nix angegeben ist es automatisch alles inklusive :)
Daran habe ich auch gedacht, wobei ich noch unsicher bin, ob ich dann wirklich knallhart alles in eine Datei, oder trotzdem jede Komponente in eine eigene kompiliere. ... Oder wahlweise :D
Aber das klingt schonmal, als sei die Idee sooo doof nicht mal.
 

Remi

New member
Die Idee ist sogar sehr gut. Das DojoToolkit hat als JavaScript-Framework das gleiche Problem: hunderte von Dateien. Dies ist auf Clientseite noch problematischer, weil dort dann (je nachdem, wie viel Komponenten eine Webseite einsetzen möchte) auch entsprechend viele Requests in Richtung Webserver gemacht werden (jede verwendete Komponente liegt in einer eigenen JavaScript-Datei und diese muß geladen werden). Die Lösung, die für das DojoToolkit gefunden wurde, ist ein spezielles "Custom Build System":
  • In einer Konfigurationsdatei gibt man an, welche Komponenten man in seiner Anwendung immer nutzen möchte und damit schnell verfügbar haben möchte.
  • Ein Java-Programm fügt dabei alle in der og. Konfigurationsdatei aufgeführten Komponenten in eine große Hauptdatei ein. Die Anwendung muß somit nur einen Request Richtung Server absetzen, um alle gewünschten Komponenten in einem Rutsch zum Client zu laden. Der Performancevorteil ist dabei enorm (nicht zu vergleichen, mit den langsamen Zugriffszeiten der DojoToolkit-Demoseiten).
  • Zusätzlich wird der Quellcode von Leerzeichen und Kommentaren befreit undVariablennamen werden "komprimiert" (alles per Option an-/abwählbar), was den Download nochmal signifikant beschleunigt.
  • Am Ende des Custom Build Prozesses liegen alle Dateien in einem /release-Verzeichnis vor. Dort liegen dann auch die Komponenten, die nicht in die große Hauptdatei eingebunden wurden. Das stellt sicher, dass man immer alle Komponenten des DojoToolkits nutzen kann - diejenigen, die sich in der Hauptdatei befinden werden in einem Rutsch geladen, alle anderen dann wieder individuell.
  • Der gesamte Build Prozess läßt sich auch für mehrere Projekte mit unterschiedlichen Anforderungen einrichten und automatisieren.
mehr Infos dazu: The Package System and Custom Builds

Wenn es sowas für das Zend Framework gäbe, wäre das genial.

Remi
 

DennisBecker

Super-Moderator
Ok, jetzt verstehe ich die Anforderung dafür erst richtig.

Dann muss man es eher als Konkurrenz zum eAccelerator ansehen als eine Ergänzung! Wer den eAccelerator nicht nutzt, weil er es nicht kann (Webhosting) der sollte auch solch eine kompilierte / komprimierte Library zugreifen können. Mit eAccelerator macht es aus meiner sicht nicht so viel Sinn, da eh alle Daten schon optimiert vorliegen nach dem 1. Aufruf.

Die Idee ist gut, brauchbar aber eher im privaten, kleinen Bereich. Sobald man einen Root-Server hat, spielt dies (theoretisch) so gut wie keine Rolle mehr (meine Meinung). Zum eAccelerator hab ich auch einen Thread eröffnet, schaut mal ins Offtopic-Forum.
 

Remi

New member
Im privaten, kleinen Bereich spielt die Performance keine wirklich wichtige Rolle. Wirklich sinnvoll sind solche Sachen im Enterprise-Bereich, hauptsächlich bei gut ausgelasteten Servern. Da lohnt es sich dann auch, Zeit und Geld in die Verbesserung der Performance zu stecken (es sei denn, eine bessere Hardwareausstattung hilft weiter und es stellt sich heraus, dass die Investitionen in Hardware wirtschaftlicher sind als andere Optimierungsansätze...).

Apropos Compiler: Sollte mit PHP6 nur ein Opcode-Cache kommen oder war eigentlich ein kompletter Compiler geplant?

Remi
 
Zuletzt bearbeitet:

DennisBecker

Super-Moderator
Dann zeigt doch mal die Vorteile auf, die durch das compilieren (eher komprimieren) der PHP-Dateien entstehen gegenüber den Byte Code Cache, welcher im Enterprise-Bereich eigentlich Standard sein sollte? Man könnte höchstens den 1. Aufruf beschleunigen, müsste dafür aber einen großen Teil seiner Appliaktion anpassen und die Aktualiserung auf eine neuere Version dürfte größeren Aufwand bedeuten.

Von daher sehe ich den Vorteil eigentlich nur bei Webhosting-Paketen, wo man keinen Zugriff auf die php.ini & apache2.conf hat.
 

Remi

New member
Nee, ich hab heute keine Lust, irgendwelche Vorteile aufzuzeigen oder gegen Bedenken zu argumentieren. ;)

Ob die Vorteile (bei Servern mit installiertem Opcode-Cache und ohne) groß oder klein sind, die ein Compiler für das Zend Framework bringen würde, wird sowieso erst ein Benchmark (nach getaner Arbeit) zeigen.

Ich find die Idee jedenfalls gut.

Remi
 
Zuletzt bearbeitet:

Blackflash

New member
Das erste, an das ich gedacht habe, war PHAR. ;-) Leider weiß ich nicht genau wie PHAR arbeitet, aber ich gehe davon aus, dass man nur einen Dateizugriff braucht. Der Rest wird ja über Wrapper erledigt.
Überlegenswert ist es auf jeden Fall, auch wenn es für mich derzeit eher das i-Tüpfelchen darstellt. :) Falls du irgendwann deine Idee umsetzen solltest, bin ich auf jeden Fall interessiert.
 

KingCrunch

New member
Dann muss man es eher als Konkurrenz zum eAccelerator ansehen als eine Ergänzung!
Immer noch: Nein! Es sind zwei unabhängige Faktoren, die sich weder widersprechen, noch untersützten -.-
Mit eAccelerator macht es aus meiner sicht nicht so viel Sinn, da eh alle Daten schon optimiert vorliegen nach dem 1. Aufruf.
Da macht es in dem Sinn wenig Unterschied, weil die eine Datei dann ebenfalls optimiert vorliegt. Trotzdem spart man den Optmierungsprozess, auch für die eine Datei ;)
Dann zeigt doch mal die Vorteile auf, die durch das compilieren (eher komprimieren) der PHP-Dateien entstehen gegenüber den Byte Code Cache, welcher im Enterprise-Bereich eigentlich Standard sein sollte?
Und nochmal: Es ist kein Komprimieren! Das wäre Phar-File ;) Und warum sollten Vorteile "gegenüber" etwas entstehen, sie widersprechen sich nicht!
Man könnte höchstens den 1. Aufruf beschleunigen, müsste dafür aber einen großen Teil seiner Appliaktion anpassen und die Aktualiserung auf eine neuere Version dürfte größeren Aufwand bedeuten.
Nein und nein ....

Du weißt aber, worum es geht?
 

KingCrunch

New member
Nochmal etwas zu eAccelerator und einer kompilierten Datei: Nehmen wir mal Zend_Translate. Wenn man das verwendet, verwendet man eh ein Großteil der Klassen. Was man nicht verwendet, sind die Adapter, die man eben net will. Und da wird jeder, der meine Beiträge gelesen hat, schnell feststellen, dass man ja garnicht alle Adapter mitkompilieren muss ;)
Zweitens: Wenn man ebenfalls meine Beiträge gelesen hat, wird man wieder erstaunt feststellen, dass ich pro Komponente eine Datei plane. Wenn man nun den ersten Punkt mitnimmt, wird man feststellen, dass es sogar für eAccelerator lohnend sein kann eine Datei zu cachen, anstatt 20. Zumindest wird es nicht bremsen.


Edit:
Mir kam auch eben spontan noch der ganz banale Komfort-Gewinn in den Sinn. Wenn vom ZF ein Update heraus kommt, kann man es sich einfach mal eben kompilieren (die Kompilierungsanweisung sollte man noch vom letzten mal rumliegen haben ;)) und muss dann nur eine handvoll (20?) Dateien hochladen/überschreiben, anstatt wie bisher entweder über 800 Dateien, oder erst die Differenz ermitteln und dann trotzdem noch sicher 500 oder 600 Dateien hochzuladen. Sicher wird dabei auch noch "guter" Code überschrieben, aber das ist meines Erachtens vernachlässigbar :)
 
Zuletzt bearbeitet:

KingCrunch

New member
Ich bin mir unsicher, aber glaube, der Ansatz tauchte hier schonmal auf. Problematisch ist dieser, weil er eine Extension vorraussetzt, die in diesem Fall auch noch recht exotisch ist.
Zusätzlich bietet es nicht den Vorteil nur eine (bzw einige wenige) Datei(en) deployen zu können.

PS: Willkommen im Forum :)
 

johnpatcher

New member
Will da auch mal meinen Senf dazugeben. Ich halte das für eine total schwachsinnige Idee. Das soll bitte niemand persönlich aufgreifen, aber eine sinnvolle Trennung macht durchaus Sinn. Würde man alles zusammenfassen müsste man bei jeder Änderung bzw. einem neuen Release das Ding neu kompilieren, in der Hoffnung, dass sich nicht irgendwelche Änderungen der Abhängigkeiten, etc. vollzogen haben. Genau das würde einen großen Vorteil der Scriptsprache PHP eliminieren.

Zudem müsste jeder sein eigenen Salat "kompilieren", da man ja das unnötige Laden von Daten, die man nicht benötigt, vermeiden möchte.

Führt man diese "Paranoia" weiter, so kann man auch auf Methoden, die keiner benötigt, oder Kommentare verzichten, das spart immerhin Platz. Dann kann man auch gleich anfangen auf PHP zu verzichten und etwas hardwarenäheres zu verwenden.

Wer wirklich Performance gut machen will bzw. muss, der greift zu anderen Dingen, wie eben dem eAccelerator, der hält das Ganze ja schon aufbereitet im Cache, egal wie viele Dateien es letztendlich sind. Da ist kein Performanceverlust feststellbar, und das trotz der "vielen" kleinen Dateien.

Auch die "heutige" Hardware hat da keine Probleme. Mit einer "richtig" eingestellten Festplatte mit dem richtigen Readahead, etc. befinden sich die Daten sowieso schon im Cache der Festplatte.

Das es bei JavaScript Frameworks ein solchen "Custom Builder" gibt ist noch einleuchtend, da hier viel Overhead (durch Requests) entsteht. Aber selbst das würde ich pauschal nicht loben. Immerhin verfügen "moderne" Browser über Cachingfunktionen, sodass dann jede Datei "einzeln" gecached werden kann, und so eventuell nicht eine komplette Datei übertragen werden muss. Außerdem hat das den Vorteil, dass wirklich auf jeder Unterseite nur das geladen wird, was benötigt wird.

Vielleicht stehe ich auch ganz allein mit meiner Meinung hier ...
 
Zuletzt bearbeitet:

KingCrunch

New member
Will da auch mal meinen Senf dazugeben. Ich halte das für eine total schwachsinnige Idee. Das soll bitte niemand persönlich aufgreifen, aber eine sinnvolle Trennung macht durchaus Sinn. Würde man alles zusammenfassen müsste man bei jeder Änderung bzw. einem neuen Release das Ding neu kompilieren, in der Hoffnung, dass sich nicht irgendwelche Änderungen der Abhängigkeiten, etc. vollzogen haben. Genau das würde einen großen Vorteil der Scriptsprache PHP eliminieren.
Richtig, genau deshalb soll es ja nen Compiler werden und keine vorkompilierten Bibliotheken.
Zudem müsste jeder sein eigenen Salat "kompilieren", da man ja das unnötige Laden von Daten, die man nicht benötigt, vermeiden möchte.
"Müsste" ist falsch, es bietet sich allerdings an, dass man (wie ich oben bereits erwähnt habe) zB beim Translate oder Db auf die Adapter verzichten kann, die in dem Kontext nicht benötigt werden.
Führt man diese "Paranoia" weiter, so kann man auch auf Methoden, die keiner benötigt, oder Kommentare verzichten, das spart immerhin Platz. Dann kann man auch gleich anfangen auf PHP zu verzichten und etwas hardwarenäheres zu verwenden.
Jetzt hast du allerdings einen grundlegenden Denkfehler: Der Compiler soll den Quelltext nicht ändern, sondern nur zusammenfassen. Das was du vorschlägst ist ein Eingriff in die Software und das lehne ich strikt ab!
Wer wirklich Performance gut machen will bzw. muss, der greift zu anderen Dingen, wie eben dem eAccelerator, der hält das Ganze ja schon aufbereitet im Cache, egal wie viele Dateien es letztendlich sind. Da ist kein Performanceverlust feststellbar, und das trotz der "vielen" kleinen Dateien.
Bitte dieses Thema nochmal durchlesen .... 1. Wurde eAcc bereits erwähnt. 2. Ist die Performance nicht der alleinige Vorteil.

Vielleicht stehe ich auch ganz allein mit meiner Meinung hier ...
Nene, aber die Argumente waren wenig aufschlussreich ;)
 

hendi

New member
Ich suche auch nach einer Möglichkeit, die Größe des Zend Frameworks zu verringern (sprich: der Benutzer muss weniger hochladen).

Ein dafür vorgesehens Tool sollte optional alle Kommentare entfernen (denn das sind eine ganze Menge, und machen bspw. bei den Dijits einen Großteil des Codes aus).

Dem Tool würde man dann sagen, welche Klassen des ZF man verwendet, und es findet dann selbstständig raus, welche Klasse davon wiederum aufgerufen werden. Nur diese benötigen Dateien werden dann von Kommentaren bereinigt (optional) und in einem neuen Ordner gespeichert, wobei jedoch die ursprüngliche Ordnerstruktur und die Dateinamen erhalten bleiben.

Es macht einfach keinen Spaß, für eine 1MB-Anwendung ein 18MB großes Framework hochzuladen, von dem ein Großteil nicht verwendet wird.
 

ice-breaker

New member
Dem Tool würde man dann sagen, welche Klassen des ZF man verwendet, und es findet dann selbstständig raus, welche Klasse davon wiederum aufgerufen werden. Nur diese benötigen Dateien werden dann von Kommentaren bereinigt (optional) und in einem neuen Ordner gespeichert, wobei jedoch die ursprüngliche Ordnerstruktur und die Dateinamen erhalten bleiben.
sitze ich momentan in meiner Freizeit dran und ist quasi schon fertig, fehlt nur noch das Design und 2-3 Dinge für den Produktiv-Betrieb, schreib mir einfach eine Nachricht mit den Komponenten die du benötigst und ich mach dir nen Package (noch manuell), als Service, dass es jeder machen kann, ist dann in einer Woche fertig.

Also um es klarzustellen, es ist kein Compiler oder ähnliches, sondern macht nur ein neues Zip-Archiv mit allen Komponenten und Dependencies die man möchte.
 
Zuletzt bearbeitet:

KingCrunch

New member
Ein dafür vorgesehens Tool sollte optional alle Kommentare entfernen (denn das sind eine ganze Menge, und machen bspw. bei den Dijits einen Großteil des Codes aus).
Kleiner Hinweis an der Stelle: Der Lizenztext muss immer mitgeliefert werden, wenn man das ZF vertreiben möchte.
Dem Tool würde man dann sagen, welche Klassen des ZF man verwendet, und es findet dann selbstständig raus, welche Klasse davon wiederum aufgerufen werden. Nur diese benötigen Dateien werden dann von Kommentaren bereinigt (optional) und in einem neuen Ordner gespeichert, wobei jedoch die ursprüngliche Ordnerstruktur und die Dateinamen erhalten bleiben.
Es ist niemals (!) empfehlenswert eine Bibliothek oder sogar ein Framework zu zerpflücken!
 
Oben