Ich programmiere ja extrem viel mit allen möglichen Programmiersprachen. Nun habe ich mir mal gedacht, ich untersuche ein bisschen, welches die schnellsten sind. Da VB allgemein als extrem langsam beschimpft wird, habe ich gleich damit begonnen.

Ich habe also mal ein kleines Programm geschrieben, welches 20'000 mal den Sinus ausrechnet. Also in etwa so:
Quellcode:
for (int x=0; x<=20000; x++)
sin(x);

Nun habe ich etwas erstaunliches festgestellt (Mit Timer auf Millisekunden-Basis):
VB als Interpreter: 20.856 Sekunden
VB als Programm: 1.279 Sekunden
(Zum Vergleich: C++: 217 Millisekunden)
Soweit so gut (oder eben nicht). Also sch**** langsam.
Jetzt gibt es aber bei VB unter Projekt / Einstellungen / Kompilieren / Optimierungen (oder ähnlich) ein paar optionen, wie keine Variablengrenzen Überprüfungen. Wenn man alle diese Optimierungen aktiviert, dann ergibt das als EXE ein Resultat von 285 Millisekunden.
(Alle Resultate wurden 20 mal berechnet und dann der Mittelwert genommen)
Also stimmt das eigentlich nicht, dass VB langsam ist. Und wenn man es so kompiliert, ist der Assambler-Code fast (mit ein paar kleinen Unterschieden) der selbe, wie der von MSVC++.
Der Unterschied wird allerdings grösser, sobald man viele DLLs, OCX und andere Komponenten verwendet.
Andere Resultate:
Delphi: 312 Millisekunden
C: 228 Millisekunden
Alle Resultate auf einem Athlon 1.4 GHz mit 256 Ram...

Falls es euch interessiert, werde ich die Exe's noch ein bisschen weiter unter die Lupe nehmen und unterschiede bzw. Performance-Optimierungen zu diesen 2 (VB und Delphi) Programmiersprachen aufschreiben.

Ich muss zuerst einmal behaupted, dass deine Art der Durchführung dieses Tests ziemlich ungeeignet ist. Was ich damit meine ist die Verwendung der Funktion Sinus, die in den C Bibliotheken sicherlich anders definiert ist als die der VB Bibliotheken. Geeigneter wäre sicherlich eine standartoperation wie die Addition zweier Zahlen.

Zitat:

Nun habe ich etwas erstaunliches festgestellt (Mit Timer auf Millisekunden-Basis):
VB als Interpreter: 20.856 Sekunden
VB als Programm: 1.279 Sekunden
(Zum Vergleich: C++: 217 Millisekunden)

Nun, mit den Optimierungsmöglichkeiten von Visual Basic kenne ich mich nicht aus, aber sicher - wenn man solch überflüssige Sachen einfach abschaltet wird der Code kürzer und somit schneller.

C ya =)

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

Ich werde also mal den Test mit den Aditionen (oder Multiplikationen) machen. Ist aber schon erstaunlich, dass VB fast gleich schnell wie C++ sein kann...

hmm das die kompillierte Form bei vb und c ähnlich schnell ist liegt daran das die berechnung des sinus einfach auf der gleichen mathematischen operation basiert. Bei einen komplexeren Programm ist der unterschied wahrscheinlich größer...

-=B.L.Ä.N.D.E.R=-

ich erinnere an die vb.dlls die man immer mitliefern muss.

- alle Angaben sind wie immer ohne Gewähr

Nun, die Ergebnisse sind eigentlich nicht weiter verwunderlich, finde ich. Der Unterschied Interpreter <-> Kompilat ist ja klar, der Unterschied Normal <-> Mit Optimierungen eigentlich auch. Es sind halt gerade Typüberprüfungen, die VB (und auch Delphi) langsam machen, dafür aber auch sicherer. Dass eine Typüberprüfung bei dem sin(x)-Programm ziemlicher Schwachsinn ist, ist klar. Aber Typüberprüfungen können durchaus Sinn machen. Unter C/C++ werden Typzuweisungen nur beim Kompilieren überprüft und ne Warnung ausgegeben, wenn was nicht zu passen scheint. Außer man hat die Warnung gleich mitdeaktiviert. Aber danach, also zur Laufzeit, kann man nem Int auch nen String zuweisen, null problemo. Das Gute daran ist, dass man damit hochoptimierten Code schreiben kann. Das Schlechte daran ist, dass das - wenn es ungewollt passiert - vor allem in großen Projekten zu enormen Fehlern führen kann.
Ein sehr gutes Beispiel, warum Überprüfungen nötig sind, ist z.B. der Buffer-Overflow Exploit, der in sehr vielen Programmen besteht. Interessanterweise sind das meist in C/C++ programmierte Programme. Denn die benutzen oft sscanf, sprintf und so weiter. Das Problem bei diesen Funktionen: Sie überprüfen nicht, ob die Länge des zu schreibenden Strings mit der Länge des Strings übereinstimmt, in den geschrieben werden soll. Durch geschickte Eingaben kann man dadurch Code-Teile überschreiben und eigenen Code ausführen, wenn der Programmierer nicht selber noch eine entsprechende Überprüfung eingebaut hat. Delphi und VB merken sowas hingegen sofort und raisen ne Exception (gah, denglisch!), die man abfangen kann - aber eben auf Kosten der Geschwindigkeit. Wer also einfach nur schnelle Programme schreiben will, oder kleine Testprogramme, den wird die geringere Geschwindigkeit nerven. Aber wer große, systemkritische Anwendungen entwickelt, der wird sich den Klick auf "Typüberprüfungen deaktivieren" nicht nur 2 mal überlegen müssen...

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy