Ein System auf Gesdchwindigkeit trimmen habe ich mal gemacht, aber das geht teils ans Eingemachte.
Tschüss Abstraktion, tschüss verschachtelte Klassen (oop ist je Abstrakter desto langsamer als functions), tschüss Joins und lange SQL, tschüss Normalisierung, tschüss Smarty, usw.
Dafür Hallo auf Speed getrimmte Tabellen und SQL, hallo für direkte Functions, Hallo ...
Aber das will keiner bei einem CMS wie Contenido wirklich machen, das ist für individuelle Sachen
Ich denke aber schon, dass man bei Modulen eine Microtime mit Logfile einbauen könnte und schauen, was Smarty so verbratet und die Klassenaufrufe, im Gegensatz zu einem bis 4.8 üblichem Modul mit Funktionen und mit ohne Smarty.
Ich gehe auch davon aus, dass die Datenbank-Abfragen gewaltig sind,
Joins und Sortierung da, wenn dann, wieso doch nicht, bei schneller Datenbank mit guter RAM Ausstattung macht das bei einem System wie Contenido nichts, aber man stelle sich Tabellen mit Millionen Zeilen Länge vor, dann bricht quasi der Datenbank-Server bei einer solchen Abfrage zusammen, weil er anfängt, mangels RAM die für die Abfrage benötigten und kurzfristig erzeugten Sortier-Tabellen auf die Festplatte aus zu lagern. Ich hab schon Fälle erlebt, da rödelte die Datenbank nicht nur 24 Stunden sondern eine ganze Woche für nur eine SQL-Abarbeitung (alles andere war natürlich blockiert, versteht sich).
Contenido funktioniert wahrscheinlich nur darum, weil es für "kleine Systeme" ist (auch Typo3, Wordpress und Joomla, nicht dass einer denkt ..., bei Wordpress war ich schon öfter ganz schnell am Limit des shared Servers, typo3 lief manchmal erst gar nicht).
Es gibt Philosophen der "Alles in die Datenbank packen"-Religion und Jünger der "Nix Datenbank, alles auf den Webserver"-Bewegung.
Beide haben sie recht und beide unrecht.
Bei Tests kam jeweils heraus, dass es weder an der Datenbank noch am Schreibprozessen auf den Webserver lag, sondern an ungünstigen Datenbank-Tabellen, an komplexen Abfragen (PHP ist oft schneller als die Datenbank), an HTTP-Requests, an Out of RAM-Memory Prozessen, an Apache (statt nginx), an sich gegenseitig blockierende Prozesse (auch mal Pausen einbauen), usw.
Bei optimalem Zugriff war weder die Datenbank langsam noch der Schreib-Lese-Zugriff auf den Server.
Da solche Logfiles schnell mal mehrere hundert Gigabyte groß werden können und dann den Sever lahm legen, sollte man ein sogenanntes Life-Log-System bauen, das bei eingestelltem Loggen jedesmal das Logfile überschreibt (also stets aktuell ist) und nur eine bestimmte Menge Daten gespeichert werden. Ruft man dann das Logfile ab, sieht man den momentanen Ist-Wert.
Bestes Format für solche Files ist HTML. Warum?
Weil man mit HTML vieles optisch besser gestalten kann und das Logfile bequem über den Browser abgerufen und betrachtet werden kann und man per Reload immer den aktuellen Stand holen kann, also somit auch einen Zeitlichen Verlauf sieht.
Naja, viele Worte.