Kennt jemand die Geschwindigkeit von VB im Gegensatz zu VC++ ?
Will sagen wenn VB auf einer Skala von 1-10 auf 5 steht ist C++ etwa... Von Java sagt man ja das es etwa 5x langsamer läuft als VC++.
Mir ist grundsätzlich klar das es unterschliedlich schnelle Methoden gibt usw.(siehe Pointer etc.) aber die reine Abarbeitungeschwindigkeit also Interpreter gegen Maschinencode, Kennt da jemand genaue Daten ?
Programmieren - alles kontrollieren 4.941 Themen, 20.708 Beiträge
ist bei den heutigen Homesystemen 800 - 1700 MHz keine Frage mehr!
Wieso ?
Er will damit sagen das es heute nicht mehr modern ist schnelle Programme zu schreiben, sondern schnelle Hardware zu fordern.
Ich arbeite in einer Firma für Echtzeitsysteme - keine Spiele - und da gibt's keine andere Wahl als C. Für manche Teile wird Fortran verwendet, gafische Oberflächen gibt's in Matlab (und das verwendet Java) und das ist wirklich laaaaaangsam.
Für Homeprogrammierung lohnt sich die 9 die C++ auf deiner Geschwindigkeitssala aber nicht.
>Er will damit sagen das es heute nicht mehr modern ist schnelle
>Programme zu schreiben, sondern schnelle Hardware zu fordern.
Falsch, die Frage war was ist schneller VB oder C++!
Um die Beiden zu vergleichen, muß man den gemeinsamen Nenner zwischen den Beiden finden d.h. die Art Applikationen die mit beiden Entwicklungsumgebungen i.d.R. erstellt werden und eben genau bei der Art von Anwendungen, ist es bei den heute vorherschenden PC Systemen völlig egal ob sie mit VB oder C++ entwickelt worden sind!
ja, den menschen moechte ich kennenlernen der bemerkt wenn sich ein fenster 2ms langsamer aufbaut......
hi.
'einfach so' einen geschwindigkeitsvergleich aufzustellen ist da nicht moeglich, die frage ist immer was man mit der sprache macht. wenn es zum beispiel darum geht speicherbereiche zu manipulieren wirst du mit vb mit sicherheit nicht froh, waehrend c++ da keinerlei probleme bereiten wird.
wenn es um das verhalten von gui elementen geht wird c++ code mit sicherheit ebenfalls 'schneller' laufen - nur wird man dort trotzdem keine spuerbaren unterschied haben.
in vielen faellen ist es auch so, das sich eine frage interpreter vs. compiler nicht stellt. angenommen im interpretercode wird eine string-such funktion verwendet. diese funktion _selbst_ stammt aus der laufzeitbibliothek des interpreters und ist _natuerlich_ _kein_ interpretierter code, d.h. die funktion selbst verhaelt sich im wesentlichen genau so, wie sie sich auch bei der verwendung in c++ verhalten wuerde. der 'performance' unterschied liegt also nur beim aufruf - die eigentliche 'zeitaufwendige' arbeit wird also hier auch nativ gemacht...
nunja, wie gesagt: man kann da nicht einfach irgendwas zum thema geschwindigkeit postulieren. beim thema flexibilitaet waere das schon anders...
WM_FYI
thomas woelfer
Wie Thomas sagte, Interpretercode ist je nach aufgerufenen Funktionen und Schleifen 1x (nur fette Befehle, die schon in der Bibiothek kompiliert vorliegen) bis 100x (nur einfache Befehle ohne Schleifen und Funktionsaufrufe) langsamer, im Durchschnitt 10x. Aber VB kann doch auch kompilieren, oder hast du nur die kostenlose Interpreterversion? Java muß übrigens gar nicht langsamer als C sein, siehe etwa http://www.aceshardware.com/Spades/read.php?article_id=154
Meinst du das mit dem SystemCode und Interpretercode ???
Zu erst währe zu klären, dass VB (zumindest ab Version 5) P-Code (Interpretercode) aber auch reinen Maschienencode erzugen kann. Um wieviel Prozent P-Code langsamer läuft als Maschienencode konnte ich nirgendwo finden, allerdings scheint das auch unwichtig zu sein, da VB den schnelleren Maschienecode erzeugen kann.
Aus der MSDN Kolumne Juli 2001:
(nachzulesen unter http://www.eu.microsoft.com/germany/ms/msdnbiblio/kolumne/)
...
Sehr einfache Tests ergeben, dass C# IL-Code max. 50% langsamer ist als C++ Maschinencode. Heutiger VB6 Maschinencode dagegen ca. 300%!
...
Sehr einfache Tests ergeben, dass C# IL-Code max. 50% langsamer ist als C++ Maschinencode. Heutiger VB6 Maschinencode dagegen ca. 300%!
...
Dabei wurde ja bisher propagiert das IL_Code genauso schnell sein soll. Ts Ts...
Das ist es doch was ich hören wollte. DANKESCHÖN !