Hallo,

ich überarbeite gerade ein Script und habe darin diesen unsäglichen Code, nur um ein HTTP-Header-formatiertes Datum zu bekommen.

my @MON = qw/Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec/;
my @WDAY = qw/Sun Mon Tue Wed Thu Fri Sat/;
my ($sec,$min,$hour,$mday,$mon,$year,$wday) = gmtime(time);
my $hdate = sprintf("%s, %02d %s %04d %02d:%02d:%02d",$WDAY[$wday],$mday,$MON[$mon],$year+1900,$hour,$min,$sec);

Habe jetzt viel gegoogelt und es scheint wohl wirklich nichts anderes zu geben, es soll ohne Modul gehen. Aber das kann doch wirklich nicht sein?

Mit Modul würde es sicherlich mit dem POSIX-Modul (das ist immer dabei, weil im Core) und dessen Funktion strftime() um einiges kürzer gehen:


Eventuell musst du hier allerdings auf die locales aufpassen, da sonst die abgekürzten Tages- und Monatsnamen in der falschen Sprache kommen.

@marky
Googlen ist nicht sinnvoll.
Suche auf CPAN oder verwende in Firefox oder Opera eine benutzerfefinierte Suche. Dann brauchst du in der Adresszeile nur cpan Date HTTP eingeben und findest:
DateTime::Format::HTTP
HTTP::Date

Hallo,

die Module habe ich auch gefunden, ich will aber wegen dem Datum kein Modul laden, das ist mir zu unperformant - ganz einfach.

Dann muss es wohl so sein, das sieht aber wirklich nicht gut aus :-)

Wie gross sind denn die Performanceeinbussen, wenn Du die Module verwendest?

marky+2008-06-02 15:08:19--

ich will aber wegen dem Datum kein Modul laden, das ist mir zu unperformant - ganz einfach.

Dann schreib es in C und binde es als XS in Perl ein. Ganz ehrlich.

Wieviele Tausend Requests pro Sekunde musst du bearbeiten?

Lass doch mal einen Benchmark laufen, ob es wirklioch so viel Performance kostet, oder kommt es auf jede µs oder ms an?

Hallo, mir geht dabei um die IO Performance, dh. den Festzugriff auf das Modul und das muss ja nicht sein, um 4 Zeile-Code zu ersetzen.

Bei Script handelt es sich um Standardprodukt und überlege wirklich fast bei jedem Konstrukt, wie es am schnellsten ist und teste fast alle Code-Varianten mit Benchmark, was übrigens sehr interessant ist.

Die Performance des System ist mit der grösste Vorteil des Produktes und alle PHP und datenbanksystem weit überlegen.

Daher bin ich da so eigen.

Ah ja. Wenn das so wartbar ist mit dem einfügen der Codezeilen anstat des Import eines Moduls, dann ist das ok.

Sicher sind ein paar Zeilen Code schneller, als der Import eiens Moduls, logisch.

marky+2008-06-02 18:36:32--

und überlege wirklich fast bei jedem Konstrukt, wie es am schnellsten ist und teste fast alle Code-Varianten mit Benchmark, was übrigens sehr interessant ist.

das mache ich auch, deshalb kann mein template-modul (HTC) auch unter mod_perl sogar
mit den template-modulen mithalten, die in C geschrieben sind. der nachteil ist jedoch,
dass es ein paar sehr fragile stellen gibt, auf die ich immer wieder aufpassen muss, wenn
ich was ändere. bei dem modul war mir die geschwindigkeit wichtiger, da es die gesamt-
performance sehr stark beeinflussen kann. schreibe ich jedoch ein skript, dann binde ich lieber
module ein, d.h. man sollte eher drauf aufpassen, dass eingebundene module schnell sind,
aber das drumherum ist nicht ganz so wichtig, da es ja die modul-funktionen sind, die
am häufigsten aufgerufen werden. sowas kann man mit einem profiler sehr schön herausfinden,
sollte man zusätzlich zu benchmarks mal probiert haben.

desweiteren würde ich nicht versuchen, ein skript so zu optimieren, dass es unter CGI am
schnellsten ist, denn wenn man wirklich performance-probleme hat, ist man eh gut beraten,
mod_perl oder FastCGI zu benutzen.

Hallo,

Wartbarkeit: die Zeilen verändern sich ja nicht, sind nur hässlich und langsam.

Thema Performance, bei einem Standardprodukt, dass von der Stange verkauft wird, kannst weder auf spezielle Module zurückgreifen und schon gar nicht auf Dinge wie mod_perl oder FastCGI - das Ding muss bei jeden 5 EUR hoster laufen - daher verwende ich nur Standardmodule wie File::Find - alles andere ist selber programmiert, wenn das auch manchmal schmerzt.