nicht angemeldet
hi,
Aber es gibt einen anderen gewichtigen(!) Grund, der gegen Perl spricht:
Bei jedem HTTP-Request auf ein Perl-CGI-Script wird der Interpreter neu gestartet, die Perl-Sources eingelesen (Moduldateien, Scriptdatei) und kompiliert. Erst dann kommt der Code zum 'Zug'. Des Weiteren muss eine etwaige DB-Verbindung auch erst einmal hersgestellt werden. Alles zusammen ist ein Overhead, der bei vielen Requests einen Server in die Knie zwingen kann, Alternativen hierzu gibt es als FastCGI oder mod_perl.
Sind diese Alternativen nicht verfügbar und soll trotzdem ein Framework mit Perl gebaut werden (pures Perl-CGI) muss der Code so schlank wie möglich sein (s. Anm.). Das mache ich bspw. so, dass Module (Klassen) nur auf Anforderung (je nach REQUEST_URI) geladen werden. D.h., anstelle use Class; verwende ich require Class;, wobei das Argument für require auch in einer Variablen stehen kann require $class; # it works, wohingegen use $class; # wrong! nicht funktioniert.
Anm.: Wie schon gesagt, nach dem Laden des Perl-Interpreters werden alle Sourcen, Source der Class main und Sources aller anderen Klassen, welche mit 'use' eingebunden sind, kompiliert. Es lohnt, sich in dieser Hinsicht einen Kopf zu machen und es ist für Perl-CGI's nahezu tödlich, bei jedem Request > 300 Methoden zu komilieren, wo für den Request selbst tatsächlich nur eine Handvoll Methoden gebraucht werden. Und? Es geht auch anders.
Schönes Osterfest ;)
Horst Haselhuhn
seth