Pro/Contra Smarty bearbeitet von ursus contionabundo 05.01.2019 12:59 > Mal ganz abseits von Template-Engines. Wenn man sein Script so baut, dass es immer *alle* Teilscripte inkludiert und eben nicht situationsabhängig kompiliert, hat man dann nach dem zweiten Seitenaufruf weniger Kompilierungsarbeit, weil PHP das letzte Kompilat gecached hat?Theorethisch? Ja.Praktisch hat man aber oft nur eine begrenzte Anzahl von Dateien, selbst im opcache.file_cache. Außerdem nützt das nicht viel, denn auch die kompilierten Skripte (aus `/path/foo.php` wird `ini_get(opcache.file_cache)/path/foo.php.bin`) werden dann includiert **und verbrauchen unnötig Speicher!**Bei Nutzung "ausreichend" atomisierter Libs mit manchmal tausenden kleinster Dateien ...~~~php<?php/* foo3.php */require LIBDIR.'foo.php';function foo3( $bar ) { return foo( $bar, 3 );}~~~...sind die Grenzen (opcache.max_accelerated_files=10000, opcache.memory_consumption=128) "schnell gerissen".Man kann sich aber einen "toten" (sonst nutzlosen) Wrapper mit allen Libs bauen und den selbst einmalig manuell aufrufen. (Aufpassen, php hat für das Ausführen in der Konsole oder unter dem Apache verschiedene INIs!. Falls man es liebt, sich unnötig Arbeit zu machen...
Pro/Contra Smarty bearbeitet von ursus contionabundo 05.01.2019 13:09 > Mal ganz abseits von Template-Engines. Wenn man sein Script so baut, dass es immer *alle* Teilscripte inkludiert und eben nicht situationsabhängig kompiliert, hat man dann nach dem zweiten Seitenaufruf weniger Kompilierungsarbeit, weil PHP das letzte Kompilat gecached hat?Theorethisch? Ja.Praktisch hat man aber oft nur eine begrenzte Anzahl von Dateien, selbst im opcache.file_cache. Außerdem nützt das nicht viel, denn auch die kompilierten Skripte (aus `/path/foo.php` wird `ini_get(opcache.file_cache)/path/foo.php.bin`) werden dann includiert. **und verbrauchen unnötig Speicher!**Bei Nutzung ausreichend atomisierter Libs mit manchmal tausenden kleinster Dateien sind die Grenzen (opcache.max_accelerated_files=10000, opcache.memory_consumption=128) "schnell gerissen".Man kann sich aber einen "toten" (sonst nutzlosen) Wrapper mit allen Libs bauen und den selbst einmalig manuell aufrufen. (Aufpassen, php hat für das Ausführen in der Konsole oder unter dem Apache verschiedene INIs!. Falls man es liebt, sich unnötig Arbeit zu machen...
Pro/Contra Smarty bearbeitet von ursus contionabundo 05.01.2019 13:01 > Mal ganz abseits von Template-Engines. Wenn man sein Script so baut, dass es immer *alle* Teilscripte inkludiert und eben nicht situationsabhängig kompiliert, hat man dann nach dem zweiten Seitenaufruf weniger Kompilierungsarbeit, weil PHP das letzte Kompilat gecached hat?Theorethisch? Ja.Praktisch hat man aber oft nur eine begrenzte Anzahl von Dateien, selbst im opcache.file_cache. Außerdem nützt das nicht viel, denn auch die kompilierten Skripte (aus `/path/foo.php` wird `ini_get(opcache.file_cache)/path/gfoo-.php.bin`) werden dann includiert.Bei Nutzung ausreichend atomisierter Libs mit manchmal tausenden kleinster Dateien sind die Grenzen (opcache.max_accelerated_files=10000, opcache.memory_consumption=128) "schnell gerissen".Man kann sich aber einen "toten" (sonst nutzlosen) Wrapper mit allen Libs bauen und den selbst einmalig manuell aufrufen. (Aufpassen, php hat für das Ausführen in der Konsole oder unter dem Apache verschiedene INIs!. Falls man es liebt, sich unnötig Arbeit zu machen...
Pro/Contra Smarty bearbeitet von ursus contionabundo 05.01.2019 13:00 > Mal ganz abseits von Template-Engines. Wenn man sein Script so baut, dass es immer *alle* Teilscripte inkludiert und eben nicht situationsabhängig kompiliert, hat man dann nach dem zweiten Seitenaufruf weniger Kompilierungsarbeit, weil PHP das letzte Kompilat gecached hat? Theorethisch? Ja. Praktisch hat man aber oft nur eine begrenzte Anzahl von Dateien, selbst im opcache.file_cache. Außerdem nützt das nicht viel, denn auch die kompilierten Skripte (aus `/path/foo.php` wird `ini_get(opcache.file_cache)/path/goo-php.bin`) werden dann includiert. Bei Nutzung ausreichend atomisierter Libs mit manchmal tausenden kleinster Dateien sind die Grenzen (opcache.max_accelerated_files=10000, opcache.memory_consumption=128) "schnell gerissen". Man kann sich aber einen "toten" (sonst nutzlosen) Wrapper mit allen Libs bauen und den selbst einmalig manuell aufrufen. (Aufpassen, php hat für das Ausführen in der Konsole oder unter dem Apache verschiedene INIs!. Falls man es liebt, sich unnötig Arbeit zu machen...
nicht angemeldet
