Zitat von
Insider2004:
Sie muss schon systembedingt langsamer sein, weil gejitted werden muss. Diesen Teil hat der dcc32 bereits beim Compilieren miterledigt. Der EXE-Nutzer wird nie wieder damit belästigt werden.
[...]
Microsoft's-.net-Java
[...]
Irgendwie habe ich gerade ein Déjà vu
Hatte gerade vor kurzem mit jemandem, der auch in diesem Thread native Anwendungen so vehement verteidigt hat, ausführlich über .NET gesprochen. Er ließ jedenfalls mit sich reden und gab zu, dass er vieles darüber noch nicht wusste. Bei dir halte ich mich kurz: Der JIT-Compiler läuft maximal einmal über den Code. Danach kann eine gecachete Version genommen werden. Wem das zuviel ist, der kann das native Image einfach mit NGEN (bereits weiter oben von Elvis erwähnt) im Vorfeld erzeugen, viele .NET-Anwendungen tun das während der Installation. Also bitte aufhören mit solchen schlicht falschen Aussagen wie "systembedingt langsamer, weil gejitted werden muss". Ich bin, obwohl absolut kein Java-Liebhaber, weder als Entwickler noch als Anwender, auch immer wieder überrascht, wie schnell Java-Anwendungen
sein können. Lieber mal richtig informieren. Ich gebe dir noch denselben Tipp wie dem letzten: Lad dir mal das
DirectX SDK runter und vergleiche die Performance der Samples, die es in C++ und in C# gibt. Du wirst überrascht sein. Und dass XNA, eine
DirectX-Version für Windows und X-Box 360, auf C# setzt, ist auch kein Zufall. Das heißt alles nicht, dass managed code die Lösung für alles und nativer Code die Wurzel allen Übels ist. Aber managed code ist auch nicht das Teufelszeug, von dem einige hier immer sprechen und die Performance ist nicht unbedingt das große Argument gegen managed code
Und wenn die Linux-Fans sich mal ein wenig vom üblichen "das kommt von Microsoft, also ist es schlecht" lösen würden, könnte sich .NET / Mono / dotGNU vielleichts sogar nochmal als das goldene Ei der Plattformunabhängigkeit erweisen. Denn ein und dieselbe Binärdatei auf Linux und Windows direkt starten zu können ist schon cooler, als den Compiler zweimal bemühen zu müssen.
Ansonsten hat Elvis, mit dem ich zwar nicht immer einer Meinung bin, aber der einfach recht hat, noch einen erheblichen Teil dazu geschrieben. Auch über das "Kaltstartverhalten" einer .NET-Anwendung, das insbesondere bei WPF-Anwendungen auffällt, das aber wie erwähnt nicht wirklich etwas mit dem Jitter zu tun hat.
Aber ich habe sogar noch etwas zum Thema. Es gibt eine neue MFC-Version? Oha. Hoffentlich wird das dann ein ähnlicher Sprung wie Direct3D 7 => 8. Ansonsten wüsste ich nicht, was in der Windows-Entwicklung noch großartig für C++ sprechen sollte, außer natürlich Qt, aber das ist dann ja nicht mehr Windows-spezifisch. Die MFC ist zwar schnell, weil ja eigentlich nur ein Thin Wrapper um die Windows
API, aber irgendwie ist sie uncool.
Was Delphi hingegen angeht, ich finde, eigentlich hat es nur eine wirkliche Schwäche, und das ist die (mangelnde) Plattformunabhängigkeit. Gäbe es die (und eigentlich ist Borland doch zum Handeln gezwungen durch Lazarus), spräche kaum noch etwas gegen Delphi. Ich meine, hey, man kann sogar die Delphi-
IDE zum Entwickeln und dann Lazarus/Freepascal zum Übersetzen verwenden
Davon abgesehen wird Delphi auch nicht wirklich sterben, solange es genug Leute verwenden. Man benutzt eine Sprache ja nicht, weil sie einen schönen Namen hat, sondern weil sie das beste Tool für einen bestimmten Zweck ist. Und Delphi ist als Sprache und Umgebung ja eigentlich immer noch sehr mächtig. Mal sehen, was draus wird
