.net-Strategie von Microsoft (?)

[Phoenix]

Zitat von Macci:

Das Problem an den ganzen platformunabhängingen System, wie eben Java oder .NET, ist einfach, dass die viel langsamer sind. Auch wenn manche was anderes behaupten, ist es nun mal so, dass ein Prozessor nativen Code VIEL schneller durchlaufen kann, als wenn er einen virtuellen Code erst mühsam über den Umweg einer virtuellen Maschine in nativen Code übersetzen muss.

Das passiert genau einmal beim ersten Aufruf einer Methode.
Mittels NGEN kann man den Prozess auch schon zur Installation machen. Was dann über bleibt ist auf das zielsystem optimierter nativer Code. Das heisst, den Aufwand des kompilierens in Nativen code wird verschoben und geht nicht mehr zu Lasten der Usability.

[Heffalump]

Zitat von bodenheim:

Warum ist es besser ein .net-Programm zu entwickeln, anstatt ein Win32-Programm?

Ich schreibe nur noch auf .Net Basis weil ich die VCL gut fand und für mich .Net die logische und vernünftige Fortsetzung ist. Wer war gleich noch einmal der geistige Vater von .Net?

[mkinzler]

Der Vater des Bruders VCL

[Bernhard Geyer]

Zitat von delphirocks:

Probiert mal den Vergleich:

Und? Ein Vergleich macht noch keine Kohl fett. Mit 5 Sekunden nachdenken kann den Durchlauf um mehr als 99% Verkürzen. Ich hatte mir auch mal 4-5 Vergleiche zusammen gestellt und da war C# um ca. 60-%80% schneller. Und ich wollte eigentlich das Gegenteil beweisen.

Evtl. sollte man sich den Artikel "C#, Java, C++ und Delphi im Effizienztest, Teil 1+2" der c't, Ausgabe 19/03 bzw. 21/03 durchlesen.

[Macci]

Naja... nichtsdestoweniger würde ich Sprachen wie C# oder Java nur benutzen, wenn es wirklich auf Platformunabhängigkeit drauf an kommt - was mir aber durchaus schon hin und wieder untergekommen ist. Ansonsten immer nur Sprachen, die echte Compiler sind und echten Maschinencode erzeugen.

[delphirocks]

@Bernhard: Naja, dann zeig' mir mal, wie du mit 5 Sekunden Nachdenken eine Winforms Applikation performant machst. Das geht nämlich dann gar nicht, ganz egal, wie lange du darüber nachdenkst. Der Einzige, der dir dann noch helfen könnte, ist der MS Mitarbeiter, der für den jeweiligen Codeteil zuständig ist.

Das Beispiel mit dem string.Format sollte ja nur zeigen, daß viele elementare Dinge in .NET saulangsam sind, wieso auch immer.
Jedenfalls verliert man (oder ich zumindest) oft die Zeit, die man ursprünglich eingesparen wollte mit der Suche nach Performance wieder.

Will nicht bestreiten, daß .NET auch viele gute Seiten hat. Die Performance zählt aber nicht dazu, speziell nicht wenn's um Winforms geht.

[jbg]

Zitat von Bernhard Geyer:

Ich hatte mir auch mal 4-5 Vergleiche zusammen gestellt und da war C# um ca. 60-%80% schneller. Und ich wollte eigentlich das Gegenteil beweisen.

Das Problem dabei ist immer die versteckte Compiler Magic und auch die zu Grunde liegende Architektur der Datentypen. Eine String-Zuweisung in .NET ist schneller als eine in Delphi, da Strings in .NET nicht Referenz gezählt sind und somit nicht threadsicher gemacht werden müssen. Ein Verändern von Strings ist in .NET aber sehr zeit spielig, da Strings nur einmal im Speicher existieren und somit ein neuer String angelegt werden muss (dafür gibt es ja die StringBuilder Klasse um diesen Nachteil auszubügeln).
Was aber auch noch zum Tragen kommt sind die vielen Bereichsüberschreitungs-Checks, die in Delphi standardmäßig abgeschaltet sind. So ist ein

Code:

string S = "Hallo";
for (int i = 0; i < S.Length; i++) 
  ch = S[i];

in C# langsamer als der entsprechende Delphi.Win32 Code, da der entsprechende Indexer den angegeben Index i bei jedem Schleifendurchlauf prüft. (Übrigens die foreach Schleife meide ich mittlerweile des öfteren in C#, da bei Millionen Aufrufen einer Methode mit einer solchen Schleife, die Enumerator-Verwaltung ganz schön zu Buche schlägt.)

Bei vorgefertigten Algorithmen ist .NET wieder klar im Vorteil, weil Delphi da einfach zu wenig bietet, außer man holt sich ein 3rdParty Produkt, dass dann aber meist nur die Funktionalität ohne entsprechende Optimierung aufweist.

Das Fazit ist, dass man in jeder Sprache Code fabrizieren kann der langsamer ist als in einer anderen Sprache. Das fängt eben schon bei den Framework- und Platformgegebenheiten an und hört bei sprachlichen Elementen noch lange nicht auf.

[Dax]

Enumeratoren betreffend: in meinen Test bewegt sich der Unterschied für eine Milliarde Elemente im Bereich von .25 Sekunden, das ist vernachlässigbar.

[Bernhard Geyer]

Zitat von delphirocks:

@Bernhard: Naja, dann zeig' mir mal, wie du mit 5 Sekunden Nachdenken eine Winforms Applikation performant machst. Das geht nämlich dann gar nicht, ganz egal, wie lange du darüber nachdenkst. Der Einzige, der dir dann noch helfen könnte, ist der MS Mitarbeiter, der für den jeweiligen Codeteil zuständig ist.

Die 5 Sekunden haben sich auf dein Beispiel bezogen. Und solche Beispiele sind immer sehr mit vorsicht zu genießen. Ich glaube mich an ein Beispiel zu erinnern in der C++ unglaublich schnell war da es einfach den kompletten Code aufgrund Nichtverwendung im Nachhinein wegoptimiert hat. Selbst bei solchen größeren Testanwendungen wie dem bekannteren Petshop wurde eigentlich primär gezeigt das die Implementierung/Architektur/Optimierung wichtiger ist als die eigentliche Sprache.

Zitat von delphirocks:

Will nicht bestreiten, daß .NET auch viele gute Seiten hat. Die Performance zählt aber nicht dazu, speziell nicht wenn's um Winforms geht.

Ich stimme dir dahingehend zu das eine portierung einer Win32-Anwendung nach .NET blos das man eine WinForms Anwendung hat ziemlich sinnlos ist (vor allem da ja WinForms eh schon wieder zu den veralteten Techniken gehört).

Zitat von jbg:

Das Fazit ist, dass man in jeder Sprache Code fabrizieren kann der langsamer ist als in einer anderen Sprache. Das fängt eben schon bei den Framework- und Platformgegebenheiten an und hört bei sprachlichen Elementen noch lange nicht auf.

Geau. Und wenn man sich einen Wechsel des Frameworks/Plattform antut sollte man nicht nur eine 1:1 Portierung durchführen sondern 10 Schritte zurückgehen und die Chance nutzen die ganze Anwendungsarchitektur nochmal zu überdenken um nicht die gleichen Kompromisse/Fehler zu machen die man bei einem gewachsenen Produkt zwangsläufig macht.

[Chemiker]

Hallo,

ich frage allein aus Interesse, weil ich von .NET Null Ahnung habe.

Zitat:

Geau. Und wenn man sich einen Wechsel des Frameworks/Plattform antut sollte man nicht nur eine 1:1 Portierung durchführen sondern 10 Schritte zurückgehen und die Chance nutzen die ganze Anwendungsarchitektur nochmal zu überdenken um nicht die gleichen Kompromisse/Fehler zu machen die man bei einem gewachsenen Produkt zwangsläufig macht.

Das Problem bei mir ist (ich Denke es geht einigen Anderen auch so), dass man Quellcode vor einiger Zeit geschrieben hat und diesen in seinen neuen Programme einbindet, ohne darüber nachzudenken. Er ist schnell und getestet. Über die Jahre sind diese Bibliotheken relativ groß geworden. Das war ja auch die Grundidee die hinter OOP steht, die Wiederverwendbarkeit.

Um mit .NET vernünftig arbeiten zu können, muss dieser Quellcode neu geschrieben werden, dass heißt man fängt wieder bei Adam und Eva an.

Bis bald Chemiker