Zitat von
QuickAndDirty:
Mit c++ mit einem Memory Manager der ne garbage collection integriert hat ist C++ sicherlich schneller.
Nö. Muß er nicht. In der c't wurde gezeigt das C++ AFAIK bei Vererbung und ähnlichen objektorientierten Techniken Delphi, C# und Java um welten langsamer war.
Zitat von
QuickAndDirty:
Das erzeugen und frei geben von Objecten ist also kein brauchbarer Geschwindigkeitsindicator.
Ist nur ein Aspekt. Wird in 95% Geschwindigkeitsvorteile bringen und in 5% der Fälle probleme Verursachen.
Zitat von
OregonGhost:
Natürlich kann man in C++ noch schneller sein.
Aber auch Langsamer. Ich würde sagen in 99% der Fälle ist ein vernünftige Implementierung (Algorithmus/Architektur) wichtiger als die verwendete Programmiersprache.
Zitat von
QuickAndDirty:
Weil dein Code in .net nicht mal nen Versionswechsel überlebt und sich die Paradigen von Dotnet mit jedem
Unterversionswechsel ändern können?
Ich denke auch .NET wird mit jeder Version stabiler werden und mit größerer Verbreitung muß selbst M$ auf verstärkter Codeschutz im Sinne von Sourceschutz achten.
Zitat von
NamenLozer:
Wenn man mal logisch nachdenkt, ist es klar, dass eine native Anwendung immer schneller ist als eine halbinterpretierte - bei gleichem Code und auch sonst gleichen Voraussetzungen natürlich. Es sei denn, der Code wird vor der Ausführung von einem JIT-Compiler in nativen Code übersetzt, was für mich aber dann den Sinn von .net in Frage stellt...
.NET und Java sind kein (halb)interpretierente Systeme. Der Code wird JIT-Compiliert und dann die compilierten Teile (bei .NET) entsprechend im System abgelegt. Dies stellt den Sinn von .NET überhaupt nicht in Frage da damit keinerlei Vorteile einer managed Plattform in Frage gestellt werden.
Zitat von
NamenLozer:
Schließlich kann ich das ganze auch mit z.B. Lazarus gleich für die entsprechende Ziel-Plattform compilieren.
Und entsprechend x Compilate bereitstellen gegenüber einem
IL-Compilat.