programming

[walker]

hi!

eine newbiefrage?

wie soll man programmieren um beste performance zu erreichen.
ein einziges langes perlscript, oder mehrere module.
wenige aber umfangreiche subroutinen oder moeglichst viele kleine sub /sub routinen

am ende wird ja doch alles geladen, somit waeren doch ein einziges script und wenige subs besser, da weniger sprungbefehle ausgefuehrt werden muessen zumindest lokal mit einem einzigen user.

es handelt sich hierbei um ein chatscript, somit habe ich sehr viele verschiedene aufrufe von verschiedenen subs

warum ich einen chat in perl mache steht hier nicht zur diskussion :) ...

scvhoenes we

ew<<

[Eternius]

Hallo,

generell ist das ziemlich egal. Es gibt Dinge die man nicht machen sollte, wenn man auf geschwindigkeit aus ist: z.b. OO benutzen.

Falls du apache zur verfügung hast: http://perl.apache.org/

gruss

[walker]

hi!

danke fuer die rasche antwort

generell ist das ziemlich egal. Es gibt Dinge die man nicht machen sollte, wenn man auf geschwindigkeit aus ist: z.b. OO benutzen.

hm, was is OO ?

Falls du apache zur verfügung hast: http://perl.apache.org/

ja laeuft auf apache, und demnaechst hab ich fuer den chat einen eigenen housingserver auch mit apache.

nun ja meine ueberlegung war zb. postcommands
ich habe verschiedene userlevel user, admin, ...
eigentlich braeuchte ich im post/ausgabe_script doch nicht die adminbefehle(sind fast mehr als chatbefehle), wenn ich die auslager wird das script kleiner, oder is das auch egal.

und wie is es mit filezugriffen, is es da besser auf eine einzige subroutine im mainscript zurueckzugreifen, oder mit jedem command einen eigenen speziellen filezugriff im sub_script abzuarbeiten (zb. wenn ich nur ip/brauser auslesen will, oder den letzten login, oder userstatus, ..

fuer den login benoetige ich den filezugriff im mainscript um alle rows zu checken und die sessionip zu generieren

ew<<

[Kim]

OO bedeutet ObjektOrientierung.

Von OO abzuraten finde ich aber grundsätzlich falsch!
Und in Sachen Performance muss man sich als Einsteiger noch nicht so die Gedanken machen. Wenn Du an Projekte rangehst, bei denen das ernsthaft eine Rolle spielt, dann hast Du eh schon mehr Erfahrung.

Gruss,

Kim

[walker]

hi!

danke, aber wenn >>OO<< das is,  was ich glaube das es is  @__@ , verwend ich es sowieso <true>nicht</true> ¡ :)

ich denke bei einem chat_script kommt es sehr wohl auf die performance an und spielt ab einer gewissen anzahl an chattern eine ernsthafte rolle¿?¿

ew<<

[opi]

Hallo walker,

danke, aber wenn >>OO<< das is,  was ich glaube das es is  @__@ , verwend ich es sowieso <true>nicht</true> ¡ :)

ich denke bei einem chat_script kommt es sehr wohl auf die performance an und spielt ab einer gewissen anzahl an chattern eine ernsthafte rolle¿?¿

heißt das, dass du alle Routinen immer wieder erneut schreiben
möchtest? Wenn du so sehr auf eine gute Performance deines
Skripts pochst, dann verwende doch eine schnellere
Programmiersprache als Perl. Wie wäre es mit C zum Beispiel?
Ansonsten würde ich auf das bisschen Performance, welche du
einsparst, wenn du alles immer wieder erneut schreibst,
verzichten.

Es ist auch ein Unterschied, ob dein Skript 5000 Zeilen oder
nur 500 hat. Du kannst auch mit Subroutinen sehr schnell
unterwegs sein :-)

Wenn du zum Beispiel immer nur Referenzen an Subroutinen
übergibst, kannst du schon sehr viel Leistung herausholen.

Die Nutzung von mod_perl oder FASTCGI wäre auch noch eine
Möglichkeit, etwas schneller unterwegs zu sein. Somit sparst
du Kompilierzeit.

Aber wie schon angedeutet... die Zeit, die du einsparst, hält
sich im Millisekundenbereich.

Greez,
opi

[waler]

hi!

verwende doch eine schnellere Programmiersprache als Perl. Wie wäre es mit C zum Beispiel?

wenn ich C koennte, ...

Es ist auch ein Unterschied, ob dein Skript 5000 Zeilen oder nur 500 hat. Du kannst auch mit Subroutinen sehr schnell unterwegs sein :-)

das is klar aber es is mittlerweile schon recht lang ( > 60k inkl. html_Scripts) die zeilen hab ich nicht gezaehlt ...

Aber wie schon angedeutet... die Zeit, die du einsparst, hält sich im Millisekundenbereich.

das is auch klar, aber auch kleinvieh macht mist und je mehr aufrufe/secunde sind desto mehr macht es sich bemerkbar denk ich

ew<<

[opi]

Hallo waler,

verwende doch eine schnellere Programmiersprache als Perl. Wie wäre es mit C zum Beispiel?
wenn ich C koennte, ...

wo ist denn das Problem? Schon zu alt für -> C <-? Kann ich mir nicht vorstellen.

Es ist auch ein Unterschied, ob dein Skript 5000 Zeilen oder nur 500 hat. Du kannst auch mit Subroutinen sehr schnell unterwegs sein :-)
das is klar aber es is mittlerweile schon recht lang ( > 60k inkl. html_Scripts) die zeilen hab ich nicht gezaehlt ...

60k mögen vielleicht 1500-2000 Zeilen bei einer übersichtlichen
Schreibweise sein.

Aber wie schon angedeutet... die Zeit, die du einsparst, hält sich im Millisekundenbereich.
das is auch klar, aber auch kleinvieh macht mist und je mehr aufrufe/secunde sind desto mehr macht es sich bemerkbar denk ich

Dazu kann ich nichts einwenden, da ich genauso denke. Aber man kann
es auch übertreiben, was die Leistung eines Skripts angeht.

Greez,
opi

[walker]

hi!

wo ist denn das Problem? Schon zu alt für -> C <-? Kann ich mir nicht vorstellen.

doch zum einen zu alt zum anderen is web (perl) eine art hobby, dafuer extra c zu lernen is der optimierungsoverkill :)
main mainjob is gameprogramming (javascript(spidermonkey), modeling, texturing, graphics, sounds, ...) der chat soll nur ein nettes feature sein, spaeter mal eine eigene .com, wir werden sehn

60k mögen vielleicht 1500-2000 Zeilen bei einer übersichtlichen Schreibweise sein.

in der entwicklung schreib ich meisst sehr uebersichtlich, doch das endprodukt wird komplett (refactored) no whitespace, no commend, und cryptische (kurze) bezeichnungen, und ja ich arbeite immer an backups :)

Aber man kann es auch übertreiben, was die Leistung eines Skripts angeht.

ich moechte raus  -||quetschen||-  was geht ;)

ew<<

[opi]

Hallo walker,

60k mögen vielleicht 1500-2000 Zeilen bei einer übersichtlichen Schreibweise sein.
in der entwicklung schreib ich meisst sehr uebersichtlich, doch das endprodukt wird komplett (refactored) no whitespace, no commend, und cryptische (kurze) bezeichnungen, und ja ich arbeite immer an backups :)

na dann viel Spaß, wenn das Original und das Backup mal abhanden
kommen und du das Skript mühselig auseinander nehmen musst.

Ausserdem... was nutzt du denn beispielsweise anstatt der print-
Anweisung, wenn du keine Funktionen nutzen möchtest :-)

Wie schaut es mit diversen anderen Perl-eigenen-Modulen aus. Nutzt
du nichts davon?

Greez,
opi

[walker]

hi!

na dann viel Spaß, wenn das Original und das Backup mal abhanden kommen und du das Skript mühselig auseinander nehmen musst.

wenn das passiert muss die festplatte meines macs crashen, ebenso der backupmac und die cds muessen vergammelt sein, in diesem fall is mir der chat relativ egal, ausserdem hab ich ein recht gutes gedaechtnis aufgrund meines alters :)
"refactoring" rechnet sich, das programm wird gesamt "knackiger" und was fertiges aendert man ja nicht mehr taeglich.

Ausserdem... was nutzt du denn beispielsweise anstatt der print- Anweisung, wenn du keine Funktionen nutzen möchtest :-)

ich sagte nicht das ich keine printanweisung nutze ;)
aber diesen html_ausgabe_modulen steh ich eher skeptish gegenueber fuer html ausgabe verwend ich lieber den direkten print bzw.
print <<"[EOF]";
[EOF]

Wie schaut es mit diversen anderen Perl-eigenen-Modulen aus. Nutzt du nichts davon?

doch :)
use CGI::Carp qw(fatalsToBrowser);
fast cgi moecht ich auch noch verwenden, wenn alles mal fertig is, wie gesagt web und perl sind eher ein hobby
das switchmodul waer auch interessant bin mehr gewohnt mit cases zu arbeiten als mit  diesen if/elsif/else latten, muss mich da noch einlesen wie das funktioniert

mir gings eher darum was sinnvoller is
1a) subroutinen oder nicht, vor allem wenn man mehrere subs verwendet.
1b) oder is es nicht einfacher alles in eine function zu schreiben.
aber das hat die erste antwort geklaert - es is egal :)

ein anderes problem scheint mir das nickfile zu sein, anfangs wenige user und schnelles einlesen, aber mit 100derten usern koennte das einlesen ein warteproblem werden?
da hab ich die moeglichkeit
2a) gesamtnickfile mit allen usern
2b) nickfile fuer jeden user extra
wobei ich persoenlich zum gesamtnickfile tendiere (maybe aus faulheit :)

ew<<

*ps mit macosx10.4.x und netscape7 is das eingabefeld des forums sehr schwer zu lesen /schriftgroesse 4px?

[opi]

Hallo,

Ausserdem... was nutzt du denn beispielsweise anstatt der print- Anweisung, wenn du keine Funktionen nutzen möchtest :-)
ich sagte nicht das ich keine printanweisung nutze ;)
aber diesen html_ausgabe_modulen steh ich eher skeptish gegenueber fuer html ausgabe verwend ich lieber den direkten print bzw.
print <<"[EOF]";
[EOF]

das habe ich auch mal versucht und es endete in einem strukturellen
Chaos, da das Ende [EOF] immer am Anfang der Zeile stehen muss.

Aber da du am Ende des Skripts sowie alles "in eine Zeile" packst,
ist das relativ egal.

Wie schaut es mit diversen anderen Perl-eigenen-Modulen aus. Nutzt du nichts davon?
doch :)
use CGI::Carp qw(fatalsToBrowser);

Wenn du keine selbstgestrickten Die-Handler nutzt, dann ist das auch
sehr sinnvoll.

fast cgi moecht ich auch noch verwenden, wenn alles mal fertig is, wie gesagt web und perl sind eher ein hobby

Falls du mal Fragen zu FASTCGI ist, dann helf ich dir gerne, da ich
selber schon öfters damit gearbeitet habe.

das switchmodul waer auch interessant bin mehr gewohnt mit cases zu arbeiten als mit  diesen if/elsif/else latten, muss mich da noch einlesen wie das funktioniert

Na jetzt widersprichst du dich aber heftig! Zum Einen möchtest du
keine Subfunktionen nutzen, aber andersrum haust du dir jede Menge
Code aus Perlmodulen in dein Skript. Dann kannst du auch mal eigene
Subs verwenden.

mir gings eher darum was sinnvoller is
1a) subroutinen oder nicht, vor allem wenn man mehrere subs verwendet.

Subroutinen sind sehr sinnvoll.

*ps mit macosx10.4.x und netscape7 is das eingabefeld des forums sehr schwer zu lesen /schriftgroesse 4px?

das verstehe ich jetzt nicht ganz, aber 4px sollte niemand lesen
müssen.

Greez,
opi

[Struppi]

Ausserdem... was nutzt du denn beispielsweise anstatt der print- Anweisung, wenn du keine Funktionen nutzen möchtest :-)
ich sagte nicht das ich keine printanweisung nutze ;)
aber diesen html_ausgabe_modulen steh ich eher skeptish gegenueber fuer html ausgabe verwend ich lieber den direkten print bzw.
print <<"[EOF]";
[EOF]

das habe ich auch mal versucht und es endete in einem strukturellen
Chaos, da das Ende [EOF] immer am Anfang der Zeile stehen muss.

so sieht es. zumal der eigene Code darüber hinaus auch noch wesentlich größer wird.

das switchmodul waer auch interessant bin mehr gewohnt mit cases zu arbeiten als mit  diesen if/elsif/else latten, muss mich da noch einlesen wie das funktioniert

Na jetzt widersprichst du dich aber heftig! Zum Einen möchtest du
keine Subfunktionen nutzen, aber andersrum haust du dir jede Menge
Code aus Perlmodulen in dein Skript. Dann kannst du auch mal eigene
Subs verwenden.

Viele Module sind kompiliert also wesentlich schneller als eigene Funktionen, zudem beinhalten sie teilweise jahrelange Entwicklungszeit sind also z.T. schon Jahre im Einsatz und robust, warum dies nicht nutzen? Wird in anderen Programmiersprachen ja auch gemacht.

Zumal Geschwindigkeitsoptimierung bei CGI Perl Skripten durch Code Einsparung eine relativ überflüssige Sache ist. Du hast soviel overhead durch Netzwerk, Server evtl. Datenbank und Fileoperationen das das was du bei dem Perlskript sparst nicht mehr ins Gewicht fällt. Aber das was du an zusätzlichen Aufwand betreiben musst um jedesmal das Rad neu zu erfinden doch erheblich sein kann. Vor allem wenn man den Umgang mit den verwendeten Modulen gelernt hat.

Bei fast cgi oder mod_perl sieht die Sache schon anders aus, aber das liegt ja nicht daran, das der Code schneller wird. ebenso läßt sich viel durch Filezugriffe und DB Operationen an Zeit rausholen. Aber wenn die Frage gestellt wird ob eine Funktion schneller ist, dann klingt das nach einer Echtzeitanwendung, die man besser direkt Maschinencode programmieren sollte. Die Einsparungen im Millisekunden bereich sind bei einer CGI Anwendung mit Sicherheit nicht relevant.

Struppi.

[walker]

hi!

Viele Module sind kompiliert , warum dies nicht nutzen?

dazu braeucht ich eindeutig mehr wissen darueber, ...

Zumal Geschwindigkeitsoptimierung bei CGI Perl Skripten durch Code Einsparung eine relativ überflüssige Sache ist. Du hast soviel overhead durch Netzwerk, Server evtl. Datenbank und Fileoperationen das das was du bei dem Perlskript sparst nicht mehr ins Gewicht fällt.

die inetverbindung is wahrscheinlich die engste pipe, aber ich denke es is ein unterschied fuer die cpu ob ich "@meine_absolut_tolle_function" oder "@matf" schreibe, vor allem wenn dann der user ungeduldig immer wieder auf submit drueckt, weil gerade sein proxy stalled, bzw gerade eine menge user "schnell" chatted.

Bei fast cgi oder mod_perl sieht die Sache schon anders aus, aber das liegt ja nicht daran, das der Code schneller wird. ebenso läßt sich viel durch Filezugriffe und DB Operationen an Zeit rausholen. Aber wenn die Frage gestellt wird ob eine Funktion schneller ist, dann klingt das nach einer Echtzeitanwendung, die man besser direkt Maschinencode programmieren sollte. Die Einsparungen im Millisekunden bereich sind bei einer CGI Anwendung mit Sicherheit nicht relevant.

maschinencode, .. wo sind die zeiten geblieben, heute haben wir nur mehr copy/paste programmierer, dafuer benoetigen wir ghz_cpus graphicboards jenseits von gut und boese um einen text zu schreiben, ... , nicht mal games werden heute noch in assembler geschrieben, ...
OK nun doch fastcgi.
was ich weiss wird das bestehende script (ohne codeaenderung) in den arbeitsspeicher geladen, daher sollte es besser sein ein moeglichst kleines (kurzes) script zu verwenden um moeglichst wenig arbeitspeicher und cpu_belastung zu belegen, vor allem wenn mehr user chatten, denke fuer jeden chatter wird das script neu in den speicher geladen, in dem fall wuerde doch der arbeitsspeicher des servers die anzahl der user beschraenken?
ie
10mbram fuer den chat / 100k_script/user = 100
bei 50k_script user = 200
bei 200k_script user = 50

ew<<

[Struppi]

OK nun doch fastcgi.
was ich weiss wird das bestehende script (ohne codeaenderung) in den arbeitsspeicher geladen, daher sollte es besser sein ein moeglichst kleines (kurzes) script zu verwenden um moeglichst wenig arbeitspeicher und cpu_belastung zu belegen, vor allem wenn mehr user chatten, denke fuer jeden chatter wird das script neu in den speicher geladen, in dem fall wuerde doch der arbeitsspeicher des servers die anzahl der user beschraenken?

Das Skript wird kompiliert, d.h. es ist egal ob die Funktion f() oder funktion() heißt.
Wie gesagt du sprichst hier über Geschwindigkeitsvorteile die wahrscheinlich nicht mal meßbar sind, selbst ohne fastcgi sind die Dateien ja i.d.R. bei häufigen Aufruf im Fetsplattern Cache und werden aus dem Arbeitspeicher gelesen.

Struppi.

[walker]

hi!

Das Skript wird kompiliert, d.h. es ist egal ob die Funktion f() oder funktion() heißt.

dh. es is egal wie umfangreich ein script is?

Wie gesagt du sprichst hier über Geschwindigkeitsvorteile die wahrscheinlich nicht mal meßbar sind, selbst ohne fastcgi sind die Dateien ja i.d.R. bei häufigen Aufruf im Fetsplatten Cache und werden aus dem Arbeitspeicher gelesen.

also die datein (message_file) sollten doch bei einem chat moeglichst nicht im cache sein, sonst gaebs ja keine neue nachrichten. das file wird ja staendig neu geschrieben
also gesucht, gefunden, geoeffnet, beschrieben, geschlossen, ausgegeben und das alles in relativ kurzen abstaenden, vorher wird aber noch abgefragt ob die nachricht privat is ein command oder public und entsprechend formatiert.

ich frag mich dann auch warum ein chat einen server "in die knie" zwingen kann? sind es nur die anfragen?

ew<<

[Struppi]

Das Skript wird kompiliert, d.h. es ist egal ob die Funktion f() oder funktion() heißt.
dh. es is egal wie umfangreich ein script is?

Dann kann es länger dauern bis es kompiliert ist. Da müssen dann aber schon einige KB dazwischen liegen.

Wie gesagt du sprichst hier über Geschwindigkeitsvorteile die wahrscheinlich nicht mal meßbar sind, selbst ohne fastcgi sind die Dateien ja i.d.R. bei häufigen Aufruf im Fetsplatten Cache und werden aus dem Arbeitspeicher gelesen.
also die datein (message_file) sollten doch bei einem chat moeglichst nicht im cache sein, sonst gaebs ja keine neue nachrichten. das file wird ja staendig neu geschrieben

Ich meinte die Module und Perl

also gesucht, gefunden, geoeffnet, beschrieben, geschlossen, ausgegeben und das alles in relativ kurzen abstaenden, vorher wird aber noch abgefragt ob die nachricht privat is ein command oder public und entsprechend formatiert.

wie schon erwähnt Dateioperationen sind Flaschenhälse, nicht Funktionsaufrufe oder Optimierung durch Vermeidung von Modulen.

ich frag mich dann auch warum ein chat einen server "in die knie" zwingen kann? sind es nur die anfragen?

Sicher, der Server beantwortet ja nur die Anfragen und, weil du schon mal die Rechenpower erwähnt hast die heute üblich ist, CGI Programme sind i.d.R. absoluter Klacks im gegensatz zu Desktopprogrammen mit einer Grafischen Oberfläche. Bei CGI prg. geht es fast immer nur um wenige KB, was heutzutage die Hardware ohne Problem sehr häufig verkraftet kann.

Struppi.

[walker]

hi!

Dann kann es länger dauern bis es kompiliert ist. Da müssen dann aber schon einige KB dazwischen liegen.

ok - verstehe

wie schon erwähnt Dateioperationen sind Flaschenhälse, nicht Funktionsaufrufe oder Optimierung durch Vermeidung von Modulen.

hm dann sollt man daran arbeiten, das die dateiverarbeitung moeglichst schnell vonstatten geht,
bzw. einzelnickfiles anlegen anstatt eines gesamtnickfiles ?

Sicher, der Server beantwortet ja nur die Anfragen und, weil du schon mal die Rechenpower erwähnt hast die heute üblich ist, CGI Programme sind i.d.R. absoluter Klacks im gegensatz zu Desktopprogrammen mit einer Grafischen Oberfläche. Bei CGI prg. geht es fast immer nur um wenige KB, was heutzutage die Hardware ohne Problem sehr häufig verkraftet kann.

darueber werd ich mehr wissen wenn ich den dezidierten server hab, bin mal gespannt

also gesamt les ich das so das es doch sehr wohl auf die groesse (kb) des scripts ankommt, zwar in kleinem bereich, aber immerhin, seis beim kompilieren oder bei cpu_leistung

ew<<

*ps mit safari is das eingabefeld des forums besser lesbar und die ladezeit gesamt wesentlich schneller als mit netscape

[Struppi]

wie schon erwähnt Dateioperationen sind Flaschenhälse, nicht Funktionsaufrufe oder Optimierung durch Vermeidung von Modulen.
hm dann sollt man daran arbeiten, das die dateiverarbeitung moeglichst schnell vonstatten geht,
bzw. einzelnickfiles anlegen anstatt eines gesamtnickfiles ?

Vermutlich schon, zumal du in diesem Falle dir keine Gedanken übers Filelocking machen musst damit sich die Prozesse nicht in die Quere kommen können.

Sicher, der Server beantwortet ja nur die Anfragen und, weil du schon mal die Rechenpower erwähnt hast die heute üblich ist, CGI Programme sind i.d.R. absoluter Klacks im gegensatz zu Desktopprogrammen mit einer Grafischen Oberfläche. Bei CGI prg. geht es fast immer nur um wenige KB, was heutzutage die Hardware ohne Problem sehr häufig verkraftet kann.
darueber werd ich mehr wissen wenn ich den dezidierten server hab, bin mal gespannt

also gesamt les ich das so das es doch sehr wohl auf die groesse (kb) des scripts ankommt, zwar in kleinem bereich, aber immerhin, seis beim kompilieren oder bei cpu_leistung

Wie gesagt, das alles muss in einer Relation mit dem Aufwand stehen unter Umständen kannst du durchaus etwas sparen, wenn du nur selbstoptimierte Routinen verwendest. Aber wenn du ein Modul konsequent nutzt sollte dein ganzer Quellcode übersichtlicher und kleiner werden, da du dann für sich oft wiederholende Aufgaben nicht immer wieder den code neu schreiben musst (ich denke da vor allem an das CGI Modul, wenn du öfters größere Formulare oder Tabellen generierst sparst du damit eine Menge ein).

Übrigens einen Chat in Perl zu programmieren ist gerade wegen der Geschwindigkeit nicht optimal, besser dafür geeignet ist z.b. Java, da du damit vom client aus kommunizieren kannst und damit wesentlich kleinere Anfragen erzeugen musst, als wenn du jedesmal die Daten komplett neu auf dem Server erzeugen musst, die ein Javaapplet ja schon hat.

Struppi.

[walker]

hi!

Übrigens einen Chat in Perl zu programmieren ist gerade wegen der Geschwindigkeit nicht optimal, besser dafür geeignet ist z.b. Java, da du damit vom client aus kommunizieren kannst und damit wesentlich kleinere Anfragen erzeugen musst, als wenn du jedesmal die Daten komplett neu auf dem Server erzeugen musst, die ein Javaapplet ja schon hat.

da magst du recht haben aber viele user bevorzugen eben einen perl oder php html chat, ich selber mag javachats auch nicht so sehr, es dauert mir zulange bis das applet geladen is und in vielen faellen stuertzt netscape einfach ab oder tut garnix ,oder safari quitiert, stalled, haengt sich einfach auf ...
desshalb html_perl, ich selber zb. hab java mittlerweile deaktiviert
es gaebe noch irc, aber auch da haben viele user bedenken wegen dem "haker_ruf" :)
der vorteil eines html chats is das er ueber jeden proxy geht, die nachteile kennen wir

und eben wegen der geschwindigkeit (serverbelastung) , moechte ich das ding so optimal machen wie moeglich einige teile wie floodcontrol bzw idletime hab ich in ein js im inputteil ausgelagert, maybe ich sollt noch mehr checks per .js machen (wash, badwords), sodass das perlscript nicht mehr soviel abarbeiten muss vor dem ausgeben.

ew<<

[opi]

Hallo,

Ausserdem... was nutzt du denn beispielsweise anstatt der print- Anweisung, wenn du keine Funktionen nutzen möchtest :-)
ich sagte nicht das ich keine printanweisung nutze ;)
aber diesen html_ausgabe_modulen steh ich eher skeptish gegenueber fuer html ausgabe verwend ich lieber den direkten print bzw.
print <<"[EOF]";
[EOF]

das habe ich auch mal versucht und es endete in einem strukturellen
Chaos, da das Ende [EOF] immer am Anfang der Zeile stehen muss.

so sieht es. zumal der eigene Code darüber hinaus auch noch wesentlich größer wird.

das switchmodul waer auch interessant bin mehr gewohnt mit cases zu arbeiten als mit  diesen if/elsif/else latten, muss mich da noch einlesen wie das funktioniert

Na jetzt widersprichst du dich aber heftig! Zum Einen möchtest du
keine Subfunktionen nutzen, aber andersrum haust du dir jede Menge
Code aus Perlmodulen in dein Skript. Dann kannst du auch mal eigene
Subs verwenden.

Viele Module sind kompiliert also wesentlich schneller als eigene Funktionen, zudem beinhalten sie teilweise jahrelange Entwicklungszeit sind also z.T. schon Jahre im Einsatz und robust, warum dies nicht nutzen? Wird in anderen Programmiersprachen ja auch gemacht.

Zumal Geschwindigkeitsoptimierung bei CGI Perl Skripten durch Code Einsparung eine relativ überflüssige Sache ist. Du hast soviel overhead durch Netzwerk, Server evtl. Datenbank und Fileoperationen das das was du bei dem Perlskript sparst nicht mehr ins Gewicht fällt. Aber das was du an zusätzlichen Aufwand betreiben musst um jedesmal das Rad neu zu erfinden doch erheblich sein kann. Vor allem wenn man den Umgang mit den verwendeten Modulen gelernt hat.

Bei fast cgi oder mod_perl sieht die Sache schon anders aus, aber das liegt ja nicht daran, das der Code schneller wird. ebenso läßt sich viel durch Filezugriffe und DB Operationen an Zeit rausholen. Aber wenn die Frage gestellt wird ob eine Funktion schneller ist, dann klingt das nach einer Echtzeitanwendung, die man besser direkt Maschinencode programmieren sollte. Die Einsparungen im Millisekunden bereich sind bei einer CGI Anwendung mit Sicherheit nicht relevant.

Struppi.

Greez,
opi

[walker]

hi

das habe ich auch mal versucht und es endete in einem strukturellen Chaos, da das Ende [EOF] immer am Anfang der Zeile stehen muss.

da hab ich kein problem.

Falls du mal Fragen zu FASTCGI ist, dann helf ich dir gerne, da ich selber schon öfters damit gearbeitet habe.

ja hab ich, davon aber ein ander mal in einem neuen thread der hier is bald im nirvana

Na jetzt widersprichst du dich aber heftig! Zum Einen möchtest du keine Subfunktionen nutzen, aber andersrum haust du dir jede Menge Code aus Perlmodulen in dein Skript. Dann kannst du auch mal eigene Subs verwenden.

ich weiss nicht wo der wiederspruch liegt, aber egal, ich moechte nur statt
if(bla_bla_0){do_bla_0}
elsif(bla_bla_1){bo_bla_1}
usw.
die switchabfrage benutzen, wenn das so geht, ...

das verstehe ich jetzt nicht ganz, aber 4px sollte niemand lesen müssen.

ich werd blind dabei, mit safari gehts besser liegt wohl daran das das eingabefeld auf pt eingestellt is nicht auf px

ew<<

[Struppi]

ich weiss nicht wo der wiederspruch liegt, aber egal, ich moechte nur statt
if(bla_bla_0){do_bla_0}
elsif(bla_bla_1){bo_bla_1}
usw.
die switchabfrage benutzen, wenn das so geht, ...

Das ist ineffizient. Wenn du oben schon nach Geschwindigkeitsvorteilen im Millisekunden bereich gefragt hast, dann ist ein switch Block nicht gerade empfehlenswert.

Sowas läßt sich schneller und übersichtlicher mit einem HASH erledigen.

#!/usr/bin/perl -w  
  
use strict;  
  
my %ACTION = (  
'bla_bla_0' => \&do_bla_0,  
'bla_bla_1' => \&do_bla_1,  
);  
  
my $what_happen = 'bla_bla_0';  
$ACTION{$what_happen}() if exists $ACTION{$what_happen};  
  
sub do_bla_0{ print "sub 0";}  
sub do_bla_1{ print "sub 1";}  

Dadurch schrumpft jeder switch Block auf eine wie ich finde lesbare Zeile. Das geht so aber nur, wenn die evtl. Parameter gleich sind.

Struppi.