Geschwindigkeit verschiedener Programmiersprachen

[Andreas Korthaus]

Hallo!

Nachdem das Forum hier eine derartigen Geschwindigkeitszuwachs erfahren hat, wollte ich mich doch mal ein wenig umhören, wie sich die  verschiedenen Programmiersprachen hier unterscheiden. Ich weiß, das kann man so pauschal nur schwer sagen, und ich weiß auch das hier im Fourm erheblich mehr passiert ist, als nur die Sprache zu wechseln, aber trotzdem wird es da ja allgemeine Tendenzen geben, vor allem in Hinblick auf Web-Applikationen:
C/C++ wird wohl verhältnismäßig schnell sein, da maschinennäher, da es ja vorher kompiliert wird.
Java ist da ja so ein Zwischending, wenn ich das richtig verstanden habe, also schon "halb-kompiliert", muß aber noch teilweise interpretiert werden, oder so ähnlich.
PHP muß komplett vom Interpreter übersetzt werden, dazu kommt noch, das der Interpreter für jedes Script neu geladen werden muß
PERL glaube ich dasselbe, nur das da noch ggfs. zig Module geladen werden, also bei Verwendung von komplexen Modulen wie CGI wird das noch erheblich langsamer als PHP...
Wie ist dagagen Phyton zu bewerten? Und ASP? JSP?

Viele Grüße
Andreas

[Cheatah]

Hi,

C/C++ wird wohl verhältnismäßig schnell sein, da maschinennäher, da es ja vorher kompiliert wird.

[...]

Wie ist dagagen Phyton zu bewerten? Und ASP? JSP?

Du hast das wesentliche schon gesagt: Nicht die Sprache an sich ist für die Geschwindigkeit verantwortlich, sondern die Art der Umsetzung in maschinennahen Code. Ein Kompilat ist da naturgemäß schneller als etwas, das bei jedem Aufruf erneut interpretiert wird. Auch das Starten eines Interpreters kostet eine gewisse "Meta-Zeit".

Allerdings gibt es noch wesentlich mehr Faktoren. So wird bei mod_perl (und für viele Sprachen gibt es ähnliches) der Interpreter beispielsweise für jeden Serverchild einmalig gestartet und bleibt dann im Speicher - diese Zeit entfällt dann. Ein weiterer, niemals zu unterschätzender Faktor ist nicht die Sprache an sich, sondern dessen Verwendung; und die des Gesamtsystems, versteht sich. Sprich: Der Algorithmus, die Optimierung der Ansprechung und Nutzung verschiedener Fremdsysteme, die Auslagerung von Programmabläufen in unabhängige Prozesse und vieles mehr helfen, ein System zu optimieren. Letzten Endes ist es quasi egal, ob der eigentliche Code nun bereits kompiliert und rasend schnell ist, oder ob jemand noch davorsitzen und den Maschinencode per Hand in den Prozessor klöppeln muss.

Cheatah

[Lude]

Auch das Starten eines Interpreters kostet eine gewisse "Meta-Zeit".

Letzten Endes ist es quasi egal, ob der eigentliche Code nun bereits kompiliert und rasend schnell ist, oder ob jemand noch davorsitzen und den Maschinencode per Hand in den Prozessor klöppeln muss.

Cheatah

Hi,

da werd' ich aber hellhörig. - Was ist "Meta-zeit" und was ist "quasi egal".

Gruss,
Luddie

[Christian Kruse]

Hallo Lude,

Auch das Starten eines Interpreters kostet eine gewisse
"Meta-Zeit".

[...]

da werd' ich aber hellhörig. - Was ist "Meta-zeit" und was
ist "quasi egal".

Mit 'Meta-Zeit' meinte Cheatah wohl die Zeit zwischen dem
eigentlichen Programmstart und dem Interpretieren des
Scripts, eben die Zeit, die der Interpreter benoetigt, um
geladen und gestart zu werden. Was mit dem anderen Statement
gemeint ist, weiss ich nicht so genau.

Gruesse,
 CK

[Michael Schröpl]

Hi Luddie,

Letzten Endes ist es quasi egal, ob der
eigentliche Code nun bereits kompiliert und
rasend schnell ist, oder ob jemand noch
davorsitzen und den Maschinencode per Hand
in den Prozessor klöppeln muss.
da werd' ich aber hellhörig. - Was ist "Meta-zeit"
und was ist "quasi egal".

der Aufwand zum Übersetzen des Programms hängt von der
Größe (näherungsweise: in Zeilen) des Programms ab.
Diese Übersetzung wird bei einem kompilierten Programm
nur einmal und bei einem interpretierten Programm immer
wieder verbraucht.

Aber die Dauer des Programmlaufs steht in keiner
Relation zur Länge des Programms - weil es Schleifen,
Rekursion und andere nette Dinge gibt.

Bei einem sehr kurz laufenden Programm kann der Unter-
schied der Laufzeit zwischen Compiler- und Interpreter-
version in Prozent sehr groß sein - aber in Sekunden
wird er vernachlässigbar sein.
Und je länger die Laufzeit des Programms insgesamt ist,
desto kleiner wird auch der Unterschied in Prozent
zwischen beiden Laufzeiten - wenn Dein Programm eine
halbe Stunde braucht, um beispielsweise einen Film von
einem Format ins andere umzucodieren, was interessieren
Dich dann die 0.5 Sekunden, die Du bei der Interpreter-
Variante durch das Interpretieren verlierst?

Das ist "quasi egal".

Der Unterschied zwischen Compiler- und Interpreter-
Version ist also dann am wichtigsten, wenn Du ein
Programm mit seeeehr kurzer Laufzeit irre oft starten
mußt. Insofern ist es nicht verkehrt, daß der Client
des neuen C-Forums ein kompiliertes Programm ist ...

Viele Grüße
      Michael

[Henryk Plötz]

Moin,

Und je länger die Laufzeit des Programms insgesamt ist,
desto kleiner wird auch der Unterschied in Prozent
zwischen beiden Laufzeiten

Mit Verlaub: Ist das so nicht nur für Interpreter wahr die mit Just-In-Time-Compilierung arbeiten? Schließlich sollte es ein Unterschied sein, ob der Prozessor gleich sein auszuführendes Kommando kriegt, oder ob der Interpreter für jedes Token (die werden ja hoffentlich vorher in einem einmaligen Durchlauf bestimmt) herausfinden muß, was er jetzt grade machen soll (inklusive häufig vorzufindendem dynamischen Typgewurschtel).

Und dieser Unterschied hängt von der Programmlaufzeit und nicht der Länge ab. Der prozentuale Unterschied zwischen Laufzeit des interpretierten und Laufzeit des compilierten Programms mag zwar kleiner werden (weil evt. vorhandene Anfangsoverhead weniger ins Gewicht fällt) wird aber eine bestimmte Grenze niemals unterschreiten.

[Christoph Schnauß]

hi Andreas ;-)

C/C++ wird wohl verhältnismäßig schnell sein, da maschinennäher, da es ja vorher kompiliert wird.

Ich glaube, so pauschal gilt das nicht. Der Geschwindigkeitszuwachs im Forum (den ewir alle erfreut zur Kenntnis genommen haben) basiert _nicht_ (oder wenigstens nicht ausschließlich) darauf, was auf dem teamone-Server passiert, sondern vor allem darauf, was su über dein CGI-Interface empfängst. Je länger der Input-String, den dein Rechner aufnehmen und verarbeiten muß, ist, desto "langsamer" ist dein Browser mit der Darstellung. Die "Maschinennähe" der verwendeten Sprache hat auf dem Server und dessen Leistungsfähigkeit Bedeutung, aber nicht mehr, wenn die abgeschickten IP-Pakete bei dir ankommen (jaja, Ergänzungen bitte von den Gurus)

Java ist da ja so ein Zwischending, wenn ich das richtig verstanden habe, also schon "halb-kompiliert", muß aber noch teilweise interpretiert werden, oder so ähnlich.

nö. JAVA wird kompiliert, fertig. Interpretiert wird da nix. Der Client muß aber entweder ebenfalls das gesamte Softwarepaket oder aber  -  für den Browser  -  mindestens ein Plugin installiert haben, das damit was anfangen kann

PHP muß komplett vom Interpreter übersetzt werden, dazu kommt noch, das der Interpreter für jedes Script neu geladen werden muß

das ist mir neu. Der Interpreter ist entweder vorhanden oder nicht vorhanden. Auch hier passiert auf Server-Seite gegebenenfalls deutlich mehr als auf Client-Seite

PERL glaube ich dasselbe, nur das da noch ggfs. zig Module geladen werden, also bei Verwendung von komplexen Modulen wie CGI wird das noch erheblich langsamer als PHP...

ich würde gerne widersprechen, weiß aber auch nicht genau, warum ...

Wie ist dagagen Phyton zu bewerten? Und ASP? JSP?

Python (mit ohne "h" hinter dem "P") ist, wenn ich das richtig verstanden habe, ebenfalls eine "interpretierte" Sprache. Das heißt, auch hier funktioniert die Kommunikation über die IP-Pakete und die Geschwindigkeit ist abhängig davon, was die Schnittstellen leisten.

ASP (inclusive VB) willst du doch jetzt niht ernsthaft diskutieren? *g*
Und für JSP gilt prinzipiell das Gleiche woe für JAVA.

Das Entscheidende ist nach meinem Kenntnisstand, wieviel "Datenmaterial" diese Sprachen der CGI-Schnittstelle übergeben. Auf dem Server sind sie alle ungefähr gleich schnell  -  ungefähr. Aber sie produzieren Ausgabestrings, die sich in der Größe erheblich unterscheiden können, und das ist wahrscheinlich das Entscheidende

Christoph S.

[Andreas Korthaus]

Hi!

Ich glaube, so pauschal gilt das nicht. Der Geschwindigkeitszuwachs im Forum (den ewir alle erfreut zur Kenntnis genommen haben) basiert _nicht_ (oder wenigstens nicht ausschließlich) darauf, was auf dem teamone-Server passiert, sondern vor allem darauf, was su über dein CGI-Interface empfängst.

Was _ich_ empfange? Das glaube ich nicht. Was hat sioch da groß geändert? Verstehd as nicht, was habe ich für ein CGI-Interface? Das hat der Server, nicht ich! Ich habe einen Browser, und der kann nur HTML & Co!
Das Forum war so langsam, weil so wie es programmmiert war, der Server kaum noch mitkam. Der Anteil den C jetzt an der Geschwindigkeit gebracht hat, ist vermnutlich nicht so hoch wie andere Faktoren, aber er wird wohl da sein, warum sollte man sonst C verwenden?

Je länger der Input-String, den dein Rechner aufnehmen und verarbeiten muß, ist, desto "langsamer" ist dein Browser mit der Darstellung.

Mein Rechner bekommt vermutlich fast denselben gz-String wie vorher, der wird entpackt und der HTML-Code wird vom Browser dargestellt. Es hat sich vor allem die Antwortzeit des Servers verkürzt.

Die "Maschinennähe" der verwendeten Sprache hat auf dem Server und dessen Leistungsfähigkeit Bedeutung, aber nicht mehr, wenn die abgeschickten IP-Pakete bei dir ankommen (jaja, Ergänzungen bitte von den Gurus)

ja, aber wenn ich mich nicht irre war der Server das Hauptproblem, die Übertragung war bereits gut ausgereitzt!

Java ist da ja so ein Zwischending, wenn ich das richtig verstanden habe, also schon "halb-kompiliert", muß aber noch teilweise interpretiert werden, oder so ähnlich.
nö. JAVA wird kompiliert, fertig. Interpretiert wird da nix. Der Client muß aber entweder ebenfalls das gesamte Softwarepaket oder aber  -  für den Browser  -  mindestens ein Plugin installiert haben, das damit was anfangen kann

PHP muß komplett vom Interpreter übersetzt werden, dazu kommt noch, das der Interpreter für jedes Script neu geladen werden muß
das ist mir neu. Der Interpreter ist entweder vorhanden oder nicht vorhanden. Auch hier passiert auf Server-Seite gegebenenfalls deutlich mehr als auf Client-Seite

PERL glaube ich dasselbe, nur das da noch ggfs. zig Module geladen werden, also bei Verwendung von komplexen Modulen wie CGI wird das noch erheblich langsamer als PHP...
ich würde gerne widersprechen, weiß aber auch nicht genau, warum ...

Wie ist dagagen Phyton zu bewerten? Und ASP? JSP?
Python (mit ohne "h" hinter dem "P") ist, wenn ich das richtig verstanden habe, ebenfalls eine "interpretierte" Sprache. Das heißt, auch hier funktioniert die Kommunikation über die IP-Pakete und die Geschwindigkeit ist abhängig davon, was die Schnittstellen leisten.

Ja, udn sind die Schnittstellen bei allen programmiersprachen gleich? Manche Interpreter müssen für jedes Script extra geladen werden, die Sprachen sind teilweise grundverschieden. Welche Schnittstelle meinst Du genau? Wenn der Apache verwendet wird, dann hat dieser die Netzwerk-Schnittstelle und jede Sprache hat eine Schnittstelle zum Apache. Es gibt doch garantiert Unterschiede zwischen den einzelnen Lösungen, oder?

ASP (inclusive VB) willst du doch jetzt niht ernsthaft diskutieren? *g*

interessieren würde es mich schon!

Und für JSP gilt prinzipiell das Gleiche woe für JAVA.

d.h. ich muß jsp kompilieren bevor ich es auf den Server lade???

Das Entscheidende ist nach meinem Kenntnisstand, wieviel "Datenmaterial" diese Sprachen der CGI-Schnittstelle übergeben. Auf dem Server sind sie alle ungefähr gleich schnell  -  ungefähr. Aber sie produzieren Ausgabestrings, die sich in der Größe erheblich unterscheiden können, und das ist wahrscheinlich das Entscheidende

Christoph S.

[Sven Schrodt]

Hallo!
[..]

Was _ich_ empfange? Das glaube ich nicht. Was hat sioch da groß geändert? Verstehd as nicht, was habe ich für ein CGI-Interface? Das hat der Server, nicht ich! Ich habe einen Browser, und der kann nur HTML & Co!

stimmt!
[..]

ASP (inclusive VB) willst du doch jetzt niht ernsthaft diskutieren? *g*
interessieren würde es mich schon!

Lass es!

Und für JSP gilt prinzipiell das Gleiche woe für JAVA.
d.h. ich muß jsp kompilieren bevor ich es auf den Server lade???

Ja! Aber es entsteht bei JSP  kein Compilat in "Maschinsprache", sondern ein sog. byte-Code, welcher von einer "virtuellen Maschine" (VM) ausgeführt wird - nicht soo schnell wie "echter" Maschinencode, aber wesentlich schneller als jeder Code, der zur Runtime erst interpretiert wird und außerdem ist es (Java) vollkommen plattformunabhängig...

Gruss und gute N8 (ich wollte schon längst schlafen...)

Sven

[Christoph Schnauß]

grüßchens ...

ASP (inclusive VB) willst du doch jetzt niht ernsthaft diskutieren? *g*
interessieren würde es mich schon!

wow, Bruder, mich auch!
Was ich da gesagt hab, war bissel provokativ gemeint. Du hast aber völlig recht: was sich im "Netz" tummelt, dürfen wir eigentlich nicht von vorneherein mit einem "pfui-button" belegen. Wir sollten schauen, was es taugt, und VB bzw. VBScript vermag durchaus einiges (die problematischen Punkte laß ich jetzt mal weg). Es geht nicht an, hier mit Ressentiments der Art: "das kommt von Microsoft und muß daher giftig sein" zu kommen.

Und für JSP gilt prinzipiell das Gleiche woe für JAVA.
d.h. ich muß jsp kompilieren bevor ich es auf den Server lade??

das "SP" im Namen "JSP" bedeutet "Server Pages". Daß das Konzept nicht ganz unbedeutend ist, kann man auch daran ablesen, daß die Apache-Leute mit TOMCAT ein eigenes Konzept dafür entwickelt haben  -  aber ich bin im Moment zu müde (und auch im ganzen Thread etwas zu verunsichert) um an der Stelle weiterzugraben, die Gefahr, daß ich mich nochmal zu undeutlich ausdrücke, ist mir zu groß ;-)

Christoph S.

[Sven Schrodt]

hallo zusammen!

PERL glaube ich dasselbe, nur das da noch ggfs. zig Module geladen werden, also bei Verwendung von komplexen Modulen wie CGI wird das noch erheblich langsamer als PHP...
ich würde gerne widersprechen, weiß aber auch nicht genau, warum ...

Perl-skripte werden _vor der ersten Ausführung_ komplett kompiliert und dann wird das Kompilat gestartet...deshalb ist Perl rel. schnell für eine Skriptsprache - und supercool ist es ohnehin.. wenn man´s mag.. denn hinter Perl stekct eine Philosophie "TMTOWTDI"...

..sorry aber mehr fällt mir um die Uhrzeit auch nicht mehr ein Bonne Nuit!

[Henryk Plötz]

Moin,

nö. JAVA wird kompiliert, fertig. Interpretiert wird da nix.

Ist es wirklich schon so spät? Ja, Javacode wird kompiliert aber: Nein, der Java-Bytecode _wird_ interpretiert. Wenn du nämlich den javac anwirfst kriegst du Bytecode raus, der im Prinzip Maschinencode ist, allerdings für eine virtuelle Maschine. Und solange du keinen Rechner hast, der Java-Bytecode frisst (die gibt es auch in echt, bin mir aber nicht sicher in welchen Stückzahlen), wird dieser auf deinem Rechner interpretiert.

(Je nach Laufzeitumgebung springt dann noch ein Just-In-Time-Compiler an, der den Bytecode während der Ausführung in Maschinencode für dein System umsetzt und sich Diesen für später merkt. Auf diese Weise können mehrfach durchlaufene Codepassagen genauso schnell laufen wie mit jeder anderen compilierten Sprache erstellte Äquivalente.)

Der Client muß aber entweder ebenfalls das gesamte Softwarepaket oder aber  -  für den Browser  -  mindestens ein Plugin installiert haben, das damit was anfangen kann

Er braucht in jedem Fall das Java Runtime Environment, ja.

das ist mir neu. Der Interpreter ist entweder vorhanden oder nicht vorhanden.

Es ist aber ein Unterschied ob der Interpreter bei jedem Seitenaufruf in den Speicher geladen (auch wenn das aus dem Plattencache geschieht) und initialisiert werden muß oder einfach der bereits laufende Interpreter sich das nächste Skript vornimmt.

--
Henryk Plötz
Grüße aus Berlin

[Cheatah]

Hi,

PHP muß komplett vom Interpreter übersetzt werden, dazu kommt noch, das der Interpreter für jedes Script neu geladen werden muß
das ist mir neu. Der Interpreter ist entweder vorhanden oder nicht vorhanden.

das Programm namens "PHP-Interpreter" ist vorhanden, ja. Allerdings kostet dieser Programmstartgenau wie jeder andere Zeit - und bei Verwendung des CG-Interfaces ist es üblich, das das aufgerufene Programm (PHP-Script) just in time gestartet wird, was genau wie an der Shell zu einem Start des zugehörigen Interpreters führt. In der Modul-Variante von PHP läuft es, wie auch bei z.B. mod_perl, anders; da gehört eine Instanz des Interpreters "zum Server" und wird daher zu jedem geforkten Serverchild distributiert. Sprich: Jeder Worker hat einen Interpreter gestartet und nutzt dien solange, bis der Worker stirbt.

PERL glaube ich dasselbe, nur das da noch ggfs. zig Module geladen werden, also bei Verwendung von komplexen Modulen wie CGI wird das noch erheblich langsamer als PHP...
ich würde gerne widersprechen, weiß aber auch nicht genau, warum ...

Weil's nicht stimmt ;-) Ja, Module werden geladen, kompiliert etc., aber das Laden geht erstens durch den dem Filesystem eigenen Cache quasi in Nullzeit (zumindest nach dem ersten Mal), und zweitens existiert hier zwischen Perl und anderen Sprachen ähnlicher Mächtigkeit - inklusive PHP - kein nennenswerter Unterschied. Die Präkompilierung des Perl-Scripts wurde ja schon erwähnt.

Python (mit ohne "h" hinter dem "P") ist, wenn ich das richtig verstanden habe, ebenfalls eine "interpretierte" Sprache.

Korrekt. Sie ist vergleichbar mit Perl und PHP, inklusive aller Vor- und Nachteile. Auch hier lässt sich der Interpreter bereits über ein Modul in den Server einbinden; wobei ich nicht verbrieft sagen kann, ob ein soclhes auch auf dem freien Markt verfügbar ist, oder ob man sich so ein Modul doch selbst bauen muss :-)

Das Entscheidende ist nach meinem Kenntnisstand, wieviel "Datenmaterial" diese Sprachen der CGI-Schnittstelle übergeben.

Nicht wirklich. Das Teuerste ist bei Netzkommunikation eh immer der Roundtrip, also ohne Betrachtigung der Datenmasse die Kommunikation  an sich; und gewöhnlich besteht ein Script nicht nur aus "Eingabe, Verarbeitung, Ausgabe", sondern beruft sich währenddessen auf andere Systeme (und sei es nur das Filesystem), welche sich oft als Bremse ausgezeichnet bewähren. Die Frage "Wie schnell ist die Sprache?" ist erst dann relevant, wenn man die Ausführung mitlesen könnte.

Auf dem Server sind sie alle ungefähr gleich schnell  -  ungefähr.

Jau. Wobei ich nur nebenbei bemerken möchte, dass der Server nur ein Programm ist, Du aber eher den Rechner meinst, auf dem _auch_ der Server läuft.

Aber sie produzieren Ausgabestrings, die sich in der Größe erheblich unterscheiden können, und das ist wahrscheinlich das Entscheidende

Nö. Ob nun ein Kilobyte zurückkommt oder hundert, das ist ein vergleichsweise marginaler Unterschied. Klar, der Empfang der Daten dauert länger, aber deswegen war das Programm nicht entsprächend lange beschäftigt.

Cheatah

[Christoph Schnauß]

hi Cheatah,

Wobei ich nur nebenbei bemerken möchte, dass der Server nur ein Programm ist, Du aber eher den Rechner meinst, auf dem _auch_ der Server läuft.

nö. Ich bin, wie du weißt, lange genug im Forum, um spätestens durch deine diversen Beiträge begriffen zu haben, daß es zwischen einem "Server-Rechner" und einem "Server-Programm" (ungenauer Begriff) deutliche Unterschiede gibt.
In der Tat steht aber meines Erachtens bei dem vom Ausgangsposting angesprochenen Thema eher der "Server-Rechner" und seine Kommunikation mit dem "Client-Rechner" (auch der "Client" kann ja eine Software sein) zur Debatte.

Ob nun ein Kilobyte zurückkommt oder hundert, das ist ein vergleichsweise marginaler Unterschied. Klar, der Empfang der Daten dauert länger, aber deswegen war das Programm nicht entsprächend lange beschäftigt.

<seufz> ich muß mir das wohl noch ungefähr siebzehnmal ins Hirn hämmern, damit ichs beim nächstenmal auch so formuliere, wie ich es eigentlich richtig gemeint habe. Wir sind da identischer Auffassung.>/seufz>

Grüße aus Berlin

Christoph S.

[Christian Kruse]

Hallo Christoph,

C/C++ wird wohl verhältnismäßig schnell sein, da
maschinennäher, da es ja vorher kompiliert wird.
Ich glaube, so pauschal gilt das nicht.

Stimmt.

Der Geschwindigkeitszuwachs im Forum (den ewir alle
erfreut zur Kenntnis genommen haben) basiert _nicht_
(oder wenigstens nicht ausschließlich) darauf, was auf dem
teamone-Server passiert,

Doch, natuerlich. Und zwar ausschliesslich. mod_gzip wurde
auch vorher schon eingesetzt.

sondern vor allem darauf, was su über dein CGI-Interface
empfängst.

Seit wann hat ein Client ein CGI? :) (Das Interface ist
doppelt gemoppelt)

Je länger der Input-String, den dein Rechner
aufnehmen und verarbeiten muß, ist, desto "langsamer" ist
dein Browser mit der Darstellung.

Richtig. Und was hat das mit der Geschwindigkeit des Forums
zu tun? Genau, nicht viel. Der HTML-Code ist naemlich sehr
aehnlich dem des alten Forums. Um genau zu sein wird
wesentlich mehr HTML ausgespuckt, wegen der Userspezifischen
Ansichten.

Gruesse,
 CK

[Christoph Schnauß]

rehallo,

C/C++ wird wohl verhältnismäßig schnell sein, da
maschinennäher, da es ja vorher kompiliert wird.
Ich glaube, so pauschal gilt das nicht.
Stimmt.

oh, gut ;-)

Der Geschwindigkeitszuwachs im Forum (den ewir alle
erfreut zur Kenntnis genommen haben) basiert _nicht_
(oder wenigstens nicht ausschließlich) darauf, was auf dem
teamone-Server passiert
Doch, natuerlich. Und zwar ausschliesslich. mod_gzip wurde
auch vorher schon eingesetzt.

nö, nicht ausschließlich, und die "Wunderwaffe" mod_gzip war hier nicht gemeint ;-)

sondern vor allem darauf, was su über dein CGI-Interface
empfängst.»»
Seit wann hat ein Client ein CGI? :) (Das Interface ist
doppelt gemoppelt)

ja, schon gut, da hab ich in der Formulierung tatsächlich heftig danebengegriffen (war auch schon ziemlich spät, wie Henryk angemerkt hat). Also:
gemeint war: "was du auf deinem Rechner entgegennehmen und verarbeiten kannst". Ich gebe zu, ich habe mich mehr als mßverständlich ausgedrückt

Je länger der Input-String, den dein Rechner
aufnehmen und verarbeiten muß, ist, desto "langsamer" ist
dein Browser mit der Darstellung.
Richtig

siehste ;-) _Das_ hatte ich eigentlich aussagen wollen, und die Konfusion im ganzen Thread ist entstanden, weil ich es zu eilig hatte, um mich kurz zu fassen

Der HTML-Code ist naemlich sehr
aehnlich dem des alten Forums

glücklicherweise. Sonst wären wir nicht mehr ganz so "zuhause", wie wir es seit längerem sind

Grüße aus Berlin

Christoph S.

[Christian Kruse]

Hallo Andreas,

PHP muß komplett vom Interpreter übersetzt werden, dazu
kommt noch, das der Interpreter für jedes Script neu geladen
werden muß
PERL glaube ich dasselbe, nur das da noch ggfs. zig Module
geladen werden, also bei Verwendung von komplexen Modulen
wie CGI wird das noch erheblich langsamer als PHP...

Das ist eine Luege.
Auch PHP hat Module. Man merkt nur nichts davon, weil sie von
PHP bei *jedem* Interpreterstart geladen werden. Egal, ob man
sie benoetigt oder nicht. Bei Perl werden sie nur dann geladen,
wenn es notwendig ist. Nicht umsonst werden httpd-Prozesse, die
mod_php benutzen, auf einmal 10, 15, 20MB gross anstatt von 1
bis 2MB.

Gruesse,
 CK

[Christoph Schnauß]

hi CK ;-)

PERL glaube ich dasselbe, nur das da noch ggfs. zig Module
geladen werden, also bei Verwendung von komplexen Modulen
wie CGI wird das noch erheblich langsamer als PHP...
Das ist eine Luege.

nu sei mal nicht gar so streng. Andreas lügt wirklich nicht, aber er hat sich hier geirrt. Es ist also keine Lüge, sondern ein Irrtum, den du gerne ausräumen darfst, dazu steht das ja im Forum ;-)

Grüße aus Berlin

Christoph S.

[Stefan Muenz]

Hallo Andreas,

Nachdem das Forum hier eine derartigen Geschwindigkeitszuwachs erfahren hat, wollte ich mich doch mal ein wenig umhören, wie sich die  verschiedenen Programmiersprachen hier unterscheiden.

Zu den Programmiersprachen wurde ja schon genug gesagt. Ich moechte noch hinzufuegen, dass ich sicher bin, dass der Geschwindigkeitszuwachs des Forums nur zu einem kleineren Teil mit der verwendeten Programmiersprache zu tun hat. Der entscheidende Punkt des Geschwindigkeitszuwachses scheint mir zu sein, dass die CGI-Anwendung des Forums selber noch mal eine Client-Server-Anwendung ist. So werden alle wichtigen, immer wieder benoetigten Daten, wie Standardkonfiguration, HTML-Templates, Forumshauptdatei(?) usw. von einem Server-Modul, also einem Forums-Daemon, der als Prozess im Arbeitsspeicher des Servers resident bleibt, bereitgehalten. Damit entfaellt das hunderttausendfache Neuladen und Vorverarbeiten immer wieder gleicher Dateien und Daten. Ausserdem wird die Prozessverwaltung des Betriebssystems wohl stark entlastet dadurch.

viele Gruesse
  Stefan Muenz

[Christian Kruse]

Hallo Stefan,

Zu den Programmiersprachen wurde ja schon genug gesagt.
Ich moechte noch hinzufuegen, dass ich sicher bin, dass
der Geschwindigkeitszuwachs des Forums nur zu einem
kleineren Teil mit der verwendeten Programmiersprache zu
tun hat.

Richtig. Aber das bessere Verhalten der Binaries unter Last
hat durchaus damit zu tun.

So werden alle wichtigen, immer wieder benoetigten Daten,
wie Standardkonfiguration, HTML-Templates,

Die gerade nicht :) Die Konfig-Dateien werden bei jedem
Programmstart geladen und geparsed. Die Templates werden
durch ein Perl-Script nach C uebersetzt, compiliert und bei
Benutzung per dlopen() dynamisch gelinkt.

Forumshauptdatei(?)

*Die* wird vom Server geholt, ja. Genau wie Postings.

Gruesse,
 CK

[Innuendo]

Hm, scheint ein kleiner "KAMPF DER GIGANTEN" zu sein!?!

;-)

und ich armes Würsterl kann nicht mal einen kleinen Batzen Senf dazu geben.

schönes WE wünscht,

Innuendo

[Christoph Schnauß]

hi Innuendo,

Hm, scheint ein kleiner "KAMPF DER GIGANTEN" zu sein!?!

nein, das ist es nicht. Die beiden "kämpfen" nicht, sondern sie "verständigen" sich. Und das ist genau das, was das Forum in toto tun will, nämlch die "Energie des Verstehens" zu fördern.

und ich armes Würsterl kann nicht mal einen kleinen Batzen Senf dazu geben.

schau mal, obs in deinem Gewürzschrank auch noch Tabasco gibt, oder, als mildere Variante, ob im Blumenkasten vor deinem Fenster Basilikum wächst ...

Christoph S.

[Thomas Schmieder]

Guten Morgen,

ich habe da ja immer das Problem mit der Auswerung der Traffic-Logs. Es kommen im Monat inzwischen ca. 2.500.000 Zeilen zusammen (und das ist erst der Anfang).

Zuerst habe ich das in PHP ausgewertet. Bei dieser Zeilenzahl läuft das Ding so 85bis 90 Sekunden bis zum Ergebnis.
Dann hat mir jemand was in Perl gestrickt. Kann ich leider noch nicht. Läuft noch ca. 25 Sekunden.
Dann habe ich was in C geschrieben. Nach vielen Abstürzen braucht das Teil noch 12 Sekunden (da scheint jetzt langsam die HDD-Gschweindigkeit zu bremsen)
Mit Freepascal erstellter Code konnte nochmal eine Steigerung auf 8 Sekunden bewirken. Die Blockbuffer scheinen einfach intelligenter gelöst zu sein und die Referred-Call Stack-Tiefe ist flacher. Das heißt, nicht so viele Unter-unter-unterfunktionen. Außerdem ist der Code nur halb so groß geworden.

Da ich früher Assembler programmiert habe, schaue ich mir bestimmt mal an, was die Composer, Compiler, und Linker daraus gemacht haben.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Kruse]

Hallo Thomas,

Zuerst habe ich das in PHP ausgewertet. Bei dieser
Zeilenzahl läuft das Ding so 85bis 90 Sekunden bis zum
Ergebnis.

Wie hast du das implementiert?
Der fgets()-Wrapper ist eigentlich recht gut geschrieben
worden.

Dann hat mir jemand was in Perl gestrickt. Kann ich leider
noch nicht. Läuft noch ca. 25 Sekunden.

Wie hast du das umgesetzt? Die Perl-IO-Geschichten sind
eigentlich sehr performant geschrieben.

Dann habe ich was in C geschrieben. Nach vielen Abstürzen
braucht das Teil noch 12 Sekunden (da scheint jetzt
langsam die HDD-Gschweindigkeit zu bremsen)

Und wie hast du das umgesetzt? Hast du Pufferndes I/O benutzt?

Mit Freepascal erstellter Code konnte nochmal eine
Steigerung auf 8 Sekunden bewirken.

FPC versteckt halt das Puffern vor dir.

Der Vergleich zieht nicht. Alles, was du damit bewiesen hast,
ist, dass verschiedene Algorithmen unter verschiedenen
Umstaenden unterschiedlich schnell sind.

Gruesse,
 CK

[Michael Schröpl]

Hi Andreas,

C/C++ wird wohl verhältnismäßig schnell sein, da
maschinennäher, da es ja vorher kompiliert wird.
Java ist da ja so ein Zwischending, wenn ich das
richtig verstanden habe, also schon "halb-
kompiliert", muß aber noch teilweise interpretiert
werden, oder so ähnlich.
PHP muß komplett vom Interpreter übersetzt werden,

keine dieser Aussagen ist korrekt, wenn Du es genau
nimmst. Überhaupt ist die ganze Fragestellung sinnlos.

Eine Sprache ist niemals "schnell" oder "langsam".
Was Du vergleichst, sind nicht Sprachen, sondern Dir
bekannte, real existierende Implementierungen zur Ver-
arbeitung von Programmen in diesen Sprachen. Davon
aber gibt es pro Sprache erheblich mehr als eine.

Eine Sprache wird aber nicht durch eine Implementie-
rung, sondern durch ihre Spezifikation definiert.
Niemand hindert Dich daran, einen Compiler oder Inter-
preter für eine beliebige Sprache zu schreiben, auch
wenn das vor Dir noch niemand getan haben sollte.
Jede Programmiersprache ließe sich auch in den Maschi-
nencode einer beliebigen, Dir genehmen Hardware über-
setzen. (Stell Dir einfach vor, Dein Compiler würde den
bisher existierenden Interpreter generieren, _der_ wäre
also das 'compilierte' Programm und Dein Programm seine
Eingabedatei, welche alternativ in Form von Konstanten
in dieses Programm eingebunden sein könnte.)
Und das kann man mehr oder weniger gut tun, so daß ein
mehr oder weniger schnelles und dabei mehr oder weniger
gut funktionierendes (!) Programm dabei herauskommt.
Lies Dir mal die Dokumentation der Optimierungstufen
eines üblichen C-Compilers durch ... es gibt Grenzen,
an denen der Optimierer zugunsten von Geschwindigkeit
das Risiko eingeht, falschen Code zu erzeugen.
Sogar derselbe Compiler angewendet auf denselben Quell-
text kann also ein unterschiedlich schnelles Resultat
produzieren!
Und wenn also nicht mal für ein konkretes Programm ei-
ner konkreten Sprache so etwas wie "die Geschwindigkeit
dieses Programms" definiert ist, wie soll da ein Ver-
gleich _verschiedener_Sprachen_ sinnvoll sein?

Es mag natürlich sein, daß ein Programm, das von einem
exotischen anderen Programm übersetzt wurde, dann dem
Charakter der entsprechenden Sprache nicht in dem Maße
entspricht, wie das vom Erfinder gedacht war.
Ein echter Java-Compiler würde natürlich keinen platt-
formunabhängigen, dafür aber sehr schnellen Code er-
zeugen, wenn man es 'richtig macht', d. h. wenn die Ge-
schwindigkeit der ausgeführten Programme das alleinige
Optimierungsziel dieses Compilers sein sollte.

Daß die real existierenden Java-Compiler das nicht tun,
hängt damit zusammen, daß die Geschwindigkeit bei der
Ausführung von Java-Programmen als weniger wichtig
angesehen wird im Vergleich zur Verwendbarkeit des
Codes auf vielen Plattformen. (Auch Sicherheitsaspekte
spielen dabei eine erhebliche Rolle - die Fähigkeiten
eines bekannten Interpreters sind besser abschätzbar
als die Fähigkeiten beliebig vieler völlig unbekannter
kompilierter Programme.)
Und es ist in bestimmten Fällen einfacher, bessere oder
sogar auf Java optimierte Hardware zu kaufen, als die
verfügbaren Ressourcen der eigenen Programmierer zu
erhöhen - es kann also billiger sein, das Tempo über
die Hardware statt über die Software zu holen, falls
die Programmierung hinreichend teuer genug ist (weil
die Problematik beispielsweise in den Inhalten steckt
und nicht in der Basis-Codierung).

Statt also Sprachen miteinander vergleichen zu wollen,
ist es schon sehr viel sinnvoller, verschiedene Imple-
mentierungen _derselben_ Sprache miteinander zu ver-
gleichen - beispielsweise Perl via CG-Schnittstelle
mit Perl als Modul: Ist der Geschwindigkeitsgewinn der
Modul-Lösung den zusätzlichen Aufwand für die sorg-
fältigere Programmierung wert, die bei Verwendung von
mod_perl notwendig ist? (Antwort: Das hängt davon ab,
wie weit der eigene Programmierstil von den Anforde-
rungen von mod_perl entfernt ist ... ;-)

Geschwindigkeit der Ausführung ist nicht alles - bei
der heutigen Leistungsfähigkeit verfügbarer Hardware
ist sie sogar in vielen Bereichen nahezu vernachlässig-
bar geworden. Ob Dein 50-Zeilen-Programm eine halbe
oder eine Viertelsekunde braucht, interessiert nieman-
den (es sei denn, es wird jeden Tag ein paar tausendmal
gestartet); aber ob Du es in 6 Monaten innerhalb von
Minuten oder Tagen (50 Zeilen voller regular expres-
sions sind viiiel Holz ...) wieder verstehst und an-
passen kannst, das ist ein meßbarer Unterschied.
Und der hängt eher von der Art der Dokumentation ab
als von der verwendeten Sprache ...

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

keine dieser Aussagen ist korrekt, wenn Du es genau
nimmst. Überhaupt ist die ganze Fragestellung sinnlos.

Wenn ich länger drüber nachdenke hast Du vollkommen recht, das war mir nur nie so klar.

Heißt das denn dann auf der anderen Seite, wenn ich ein Script in PHP und in C theoretisch abslut gleich programmmiert habe, also das der Ablauf derselbe ist, das das Scipt vom Ablauf her etwa gleich lange braucht, halt bis auf die Unterschiede die durch das vermutlich nicht gleiche Ergebnis des Kompilierens zurückzuführen sind?

Also wäre der hauptsächliche Vorteil von C das einfach die Zeit des interpretierens, ggfs. noch die Zeit des Ladens eines Interpreters und was so dazu gehört wegfällt, was sich bei häufigem Aufrufen des Scriptes bemerkbar macht. Außerdem hat man hier noch mehr Einfluß auf die Implementierung, nicht nur innerhalb des Sciptes hängt der Ablauf mehr von den eigenen Fähigkeiten ab als von bereits standardmäßig implementierten Funktionen, und vor allem beim Kompilieren... kann man noch Einfluß auf den Maschinencode nehmen. Auch wenn das bei PHP... theoretisch auch ginge, aber das macht ja keiner, bei PHP sehe ich vor allem den Vorteil der Einfachheit, vor allem für Anfänger lassen sich schon recht interessante vor allem Web-Anwendungen schreiben, und läßt sich dabei später gut anpassen.

Aber ist das tatsächlich so das JSP-Scripte vorm Hochladen auf den Server erst kompiliert werden müssen? Das macht deren Anwendung ja schonmal komplizierer als PHP, aber dafür ist eine JSP Lösung gegenüber einer verglichbaren PHP-Lösung vermutlich etwas belastbarer.

Viele Grüße und Danke für die Erläuterung,
Andreas

[Sven Rautenberg]

Moin!

Aber ist das tatsächlich so das JSP-Scripte vorm Hochladen auf den Server erst kompiliert werden müssen? Das macht deren Anwendung ja schonmal komplizierer als PHP, aber dafür ist eine JSP Lösung gegenüber einer verglichbaren PHP-Lösung vermutlich etwas belastbarer.

Nein, JSP-Seiten werden, falls noch nicht geschehen, beim ersten Seitenaufruf kompiliert - ganz automatisch. Das bedeutet, dass der erste Seitenbesuch ziemlich lahm ist - alle weiteren Besuche dann aber sehr schnell funktionieren, weil die kompilierte Version genutzt wird.

Und da man in der Regel selber ausprobieren wird, ob die Seite ordentlich auf dem Server angekommen ist etc., dürften Besucher von diesem Vorgang nur ganz selten etwas merken.

- Sven Rautenberg

[Andreas Korthaus]

Hallo!

Nein, JSP-Seiten werden, falls noch nicht geschehen, beim ersten Seitenaufruf kompiliert - ganz automatisch. Das bedeutet, dass der erste Seitenbesuch ziemlich lahm ist - alle weiteren Besuche dann aber sehr schnell funktionieren, weil die kompilierte Version genutzt wird.

Und da man in der Regel selber ausprobieren wird, ob die Seite ordentlich auf dem Server angekommen ist etc., dürften Besucher von diesem Vorgang nur ganz selten etwas merken.

Das hört sich sehr interessant an, eine ziemlich intelligente Lösung, ist also JSP die Web-Programmiersprache der Stunde? Vermutich ist es wieder die falsche Herangehensweise, aber ich weiß nicht so recht wie ich sonst drangehen soll. Zumindest habe ich kürzlich mit jemandem(Geschäftsführer) der wirklich viel Ahnung von dem Geschäft hat, und sehr erfolgreich Webanwendungen programmiert hat(Unternehmen an Börse notiert) gesprochen, und nur als ich "PHP" in den Mund genommen hat hat er seine Augen verdreht.  Gerade bei "Professionellen" hat z.B. PHP ein extrem schlechtes Ansehen, im Gegensatz zu ASP und JSP. Gut, ich kenne jetzt JSP noch überhaupt nicht und ASP nur ein wenig, aber im Vergleich zu PHP hat ASP in meinen Augen erhebliche Nachteile! Alleien wenn ich eine email verschicken will, oder einen Upload ermöglichen oder Thumbnails erstellen will, das ganze ist in ASP erheblich komplizierter als in PHP, abgesehen davon mag ich VB nicht.

Gut, von JSP höre ich nur Gutes, aber wie gesagt habe ich davon keine Ahnung. Soweit ich weiß haben ASP und JSP aber einen entscheidenen Vorteil gegenüber PHP und PERL:
sie sind in eine komplette Entwicklungsumgebung integriert, d.h. mit .NET oder entsprechenden JAVA-Frameworks werden ja ganze Unternehmens-Anwendungen(Abteilungs- und sogar Unternehmens-Übergreifend) programiert, die sämtliche Abläufe im Unternehmen abbilden, oder z.B. für SAP R3... Voraussetzung sind. Und hier lassen sich eben ASP bzw. JSP hervorragend integrieren, so dass man am Ende eine "runde Sache" hat. Die Frage ist nur in wie vielen Fällen man das braucht? Mit Abstand die meisten kleinen und mittelständischen Unternehmen werden solch komplexe Software-Strukturen gar nicht verwenden, aber trotzdem ist das Image von PHP auch hier mieserabel.

Aber ich verstehe es einfach nicht. Man kann auch mit ASP "Schrott" produzieren, wenn ich mich in PHP an ein paar "Sicherheitsrichtlinien", wie sie im Manual dokumentiert sind halte, dann kommt auch hier mit sehr geringem Programieraufwand sehr gute Software zu Stande. Natürlich wird PHP inzwischen von den meisten Leuten als Einstieg in die dynamische Web-Programmierung verwendet, die aus der HMTL/JS Ecke kommen, und im Prinzip keine Ahnung von Programmieren haben, und so anfangs unweigerlich schlechten und unsicheren code erzeugen, was seit PHP 4.2, wenn es sich den mal durchgesetzt hat, besser werden sollte. ASP/JSP wird aus verschiedenen Gründen nur von professionelleren Programierern benutzt, die somit auch professionellere Anwendungen hinbekommen.

Was mich daran wirklich stört, ist das meine Anwendungen und damit auch mein Wissen nur augrund der Verwendung von PHP als Prorammiersprache abgewertet werden, wobei eine Programiersprache doch wirklich nur "Mittel zum Zweck" sein sollte, und das man die Sprache die einem am besten liegt und vor allem die den angefragten Zweck am besten erfüllt verwenden sollte. Gerade bei Web-Anwendungen ist das in meinen Augen sehr oft PHP.

IMHO sind PERL und C für Web-Anwendungen keine wirklich Alternative, ich meine jetzt vor allem Pyton(war das jetzt richtig?), ASP und JSP.
An ASP stört mich wie gesagt vor allem die Beschränktheit und Abhängigkeit von vielen anderen Programmen.

Was jetzt an Pyton großartig besser ist als an PHP weiß ich auch nicht, ich kenne pyton auch nicht, nur wurde es in diesem Forum jetzt schon mehrmals über PHP gestellt. Ein Vorteil wäre zweifelsfrei ein besseres Image als PHP.

JSP höre ich jetzt immer öfter sei das non-plus-ultra vor allem für komplexere Anwendungen. OK, das mit dem "einmal Kompilieren" ist schon eine gute Sache.
Heißt das jetzt also man soll Java lernen und JSP den Vorzug geben? Wie gesagt, mir ist bewußt das Programiersprachen immer nur ein Mittel zum Zweck sind, aber es interesiert mich, in welcher Sprache Ihr die Zukunft seht, in welcher Sprache sich am besten professionelle und komplexe Webanwendungen porgramieren lassen.

Viele Grüße
Andreas

[Christian Kruse]

Hallo Andreas,

Heißt das denn dann auf der anderen Seite, wenn ich ein
Script in PHP und in C theoretisch abslut gleich
programmmiert habe, also das der Ablauf derselbe ist, das
das Scipt vom Ablauf her etwa gleich lange braucht, halt
bis auf die Unterschiede die durch das vermutlich nicht
gleiche Ergebnis des Kompilierens zurückzuführen sind?

Nein, nicht komplett. Da hat Michael uebertrieben. Man muss
durchaus die durch die Script-Sprache gebotene
Abstraktions-Ebene beruecksichtigen. Einen Syntax-Baum
auszufuehren dauert durchaus laenger, als die Anweisungen
direkt weiterzugeben. Dazu kommen eventuelle Probleme bei
der Abstraktion der I/O-Geschichten...

Also wäre der hauptsächliche Vorteil von C das einfach die
Zeit des interpretierens, ggfs. noch die Zeit des Ladens
eines Interpreters und was so dazu gehört wegfällt, was
sich bei häufigem Aufrufen des Scriptes bemerkbar macht.

Einmal das, ja, aber man kann auch viel Plattform-
spezifischer arbeiten. Beispiel: auf x86-Plattformen ist es
sinnvoller, einen int anstelle eines char zu benutzen, weil
der int im Normalfall die natuerliche Groesse eines Systems
darstellt. Kann halt einfach besser verarbeitet werden. Man
kann halt viel besser und genauer optimieren.

Gruesse,
 CK