Regexp prozessor/RAM Lastiger als $cgi->param ??

[Aquariophile]

Hallo

Abgesehen dass es einfacher ist $cgi->param ... zu verwenden
um an Variablen ranzukommen,
jetzt nur mal auf RAM und CPU bezogen:

Ich hörte REGEXP ist angeblich RAM und CPU belastender,
als die variables vom $ENV{'QUERY_STRING'} mit

1. split
2. $cgi->param

zu bekommen.

Stimmt das?
Wenn ja (haben einige gesagt) wieso ist das so?
Warum belastet eine REGEXP den CPU / RAM mehr als "split" oder $cgi->param?

Funktionieren tut das was ich will auf alle 3 Möglichkeiten,
nun hab ich die Qual der wahl ass ich nicht wieß welche ich nehmen soll.

Bitte wirklich nur von CPU und RAM ausgehen
einfach vergessen was davon "einfacher" anzuwenden ist

Danke!
Aquariophile

[K@rl]

Hallo Aquariophile,

Deine Sorgen möcht' ich haben. Betreibst Du Deinen Webserver auf einem Nintendo Gameboy Advance?

mit einem deutlichen "IMVHO" vorangestellt: zerbrech' Dir darüber nicht den Kopf .. und verwende die CGI Bib.

Grüße
   K@rl

[Wilhelm]

Hi,

Deine Sorgen möcht' ich haben.

Ich nicht! *g*

Betreibst Du Deinen Webserver auf einem Nintendo Gameboy Advance?

Der Spruch der Woche!

So wie es aussieht, programmiert er einen Webserver fuer das Teil. Ich will ja nur hoffen, dass auch eine Vernetzung via Linkkabel zu den alten Modellen moeglich ist. Der Sohn meiner LG hat noch 2 so Uraltteile. Vielleicht kann dann einer als Firewall dienen (damit die Pokemon keinen Unsinn anrichten koennen *g*)

Gruesse
Wilhelm

[K@rl]

Hallo Wilhelm,

So wie es aussieht, programmiert er einen Webserver fuer das Teil. Ich will ja nur hoffen, dass auch eine Vernetzung via Linkkabel zu den alten Modellen moeglich ist. Der Sohn meiner LG hat noch 2 so Uraltteile. Vielleicht kann dann einer als Firewall dienen (damit die Pokemon keinen Unsinn anrichten koennen *g*)

Meines Wissens nach ist die Verkabelung nicht mit dem alten GB nicht möglich. Aber nicht uninteressant: die Firma Singer bietet eine Steuerung für eine ihre Nähmaschinen über den 8-Bit GB an. Bin mal gespannt, was sich die Leute mit dem 32-Bit GBA ausdenken werden(Kampjets?, Auto mit "Drive by Wire"?, AKWs?)

Mein Neffe hat seit Weihnachten auch so ein Teil. Hab's zwei Wochen vorher gekauft und mal ausprobiert ob er wohl damit zurechtkommt .. und mir dann überlegt, ob er sich nicht auch über ein nettes Paar Socken freut. - Gleich am Tag der Geschenkgebung hat er dann meine grandiosen, in zwei Wochen hart erarbeiteten Erfolge bei "Super Mario 2" ziemlich locker überboten <grmpf!>

Grüße
   K@rl

[Wilhelm]

Hi

Mein Neffe hat seit Weihnachten auch so ein Teil. Hab's zwei Wochen vorher gekauft und mal ausprobiert ob er wohl damit zurechtkommt .. und mir dann überlegt, ob er sich nicht auch über ein nettes Paar Socken freut. - Gleich am Tag der Geschenkgebung hat er dann meine grandiosen, in zwei Wochen hart erarbeiteten Erfolge bei "Super Mario 2" ziemlich locker überboten <grmpf!>

Vermutung: nach einer halben Stunde machte er Dich platt!

Ein weiser Ratschlag aus Erfahrung:

Lass Dich nicht mit den Kids auf Konsolen- oder GB-Spiele ein. Man holt sich eine blutige Nase. *g* Die sind da einfach besser drauf.

Gruesse
Wilhelm

der nie wieder Mario-Cart mit Kids spielt, da diese irgendwelche geheime Insiderinfos haben, wie man abkuerzen oder Gegner abschiessen kann.

[Cheatah]

Hi,

Ich hörte REGEXP ist angeblich RAM und CPU belastender,

[...]

Stimmt das?

find's heraus:

perldoc Benchmark

Für die Entscheidung, welche Variante verwendet wird, ist _hier_ die CPU-Belastung aber unerheblich. Es geht um (potentielle) Fehler (milliardenfach getestetes CGI.pm gegen "Deinen Code"), Wartbarkeit (neue Modulversion gegen die Veränderung jedes einzelnen Scripts), und nicht zuletzt auch um die Qualität und Quantität der Features - kommt split/RegExp mit Fileuploads zurecht?

Wenn ja (haben einige gesagt) wieso ist das so?

Wenn ja, dann liegt's vermutlich daran, dass CGI.pm geringfügig mehr macht, als ein individuell angepasstes "ich mach nur was zwingend sein muss"-Script. Es ist eben allgemeingültig[1] gehalten - mit allen Vor- und Nachteilen.

[1] Wobei die Standard-Module sich gewöhnlich auch dadurch auszeichnen, dass Dinge erst dann gemacht werden, wenn sie gebraucht werden. AFAIK liest CGI.pm die URL-/POST-Parameter bei der ersten Verwendung von param() aus.

Funktionieren tut das was ich will auf alle 3 Möglichkeiten,

Wenn Du plötzlich etwas (geringfügig) anderes willst, funktioniert es aber u.U. nur noch mit einer Möglichkeit. Wie diese heißt, brauche ich wohl nicht zu erwähnen :-)

nun hab ich die Qual der wahl ass ich nicht wieß welche ich nehmen soll.

CGI.pm. Es existiert keine nutzbare Alternative.

Bitte wirklich nur von CPU und RAM ausgehen

Das sind irrelevante Kriterien.

einfach vergessen was davon "einfacher" anzuwenden ist

Dieses Kriterium ist noch irrelevanter: Wenn Du eine fertige Funktion vorliegen hast, ist jede der drei Methoden vergleichbar einfach anzuwenden.

Cheatah

[Michael Schröpl]

Hi,

Ich hörte REGEXP ist angeblich RAM und CPU belastender,
als die variables vom $ENV{'QUERY_STRING'} mit

1. split
2. $cgi->param
   zu bekommen.
   Stimmt das?

Vermutlich ja - plausibel wäre es.

Wenn ja (haben einige gesagt) wieso ist das so?

Weil es viel mehr tut.

Warum belastet eine REGEXP den CPU / RAM mehr als "split"
oder $cgi->param?

Weil der Interpreter für regular expressions im allgemeinen Fall (!) mit sehr viel mehr Möglichkeiten rechnen muß (selbst wenn Du einen "einfachen" regulären Ausdruck anwenden willst) als der Interpreter für split() - daraus folgt, daß es sehr wahrscheinlich ist, daß der Code für letzteren einfacher und besser optimierbar ist. (Alleine schon die Abfragen, ob einer dieser potentiellen Sonderfälle vorliegt, kostet halt etwas - im Vergleich zur "Spar-Variante", die das gar nicht erst kann.)

Funktionieren tut das was ich will auf alle 3 Möglichkeiten,
nun hab ich die Qual der wahl ass ich nicht wieß welche ich
nehmen soll.

Diejenige, welche Dir unter Berückichtigung aller (!) Randbedingungen die größten Vorteile bietet.

Bitte wirklich nur von CPU und RAM ausgehen

Genau wie Cheatah halte ich das für ein äußerst ungeeignetes Kriterium.
Denn der Ressourcenverbraucht bei der Interpretation der paar dutzend Bytes Deines QUERY_STRING ist, verglichen mit anderen Schritten der Verarbeitung (beispielsweise dem Laden des Perl-Interpreters!) so was von irrelevant, daß der Unterschied selbst dann kaum meßbar wäre, falls eine der drei Möglichkeiten zehnmal so performant wäre wie eine andere (was ich nicht glaube).
So hoch getuned kann Dein System einfach nicht sein (auch nicht mit mod_perl und ähnlichen "Nachbrennern"), daß es Dir auf die paar Maschinenbefehle ankommen könnte.

Verglichen damit sind die Argumente der Software-Wartbarkeit, Zuverlässigkeit und Portabilität, die Cheatah bereits genannt hat. überwältigend.

Kurz gesagt. Wenn Du Dir über solche Aspekte Gedanken machen mußt, dann ist Perl grundsätzlich die falsche Sprache für Dich - möglicherweise sogar auch C, und es bleibt nur Assembler übrig.
Solche Maßstäbe würde ich allerdings heutzutage nur noch bei plattform- und graphikkartenabhängigen Programmierungen (Spiele, Kernroutinen der Betriebssystem-Schicht für Fensterverwaltung etc. - beispielsweise das, womit sich die Mozilla-Programmierer im Moment herum schlagen müssen) und ähnlichen Exoten anlegen - aber bestimmt nicht bei CGI-Skripten, wo die langsamen Leitungen ohnehin alles ausbremsen.

Viele Grüße
      Michael