Wie schätzt Ihr die Weiterentwicklung von .NET ein?

[Insider2004]

Zitat von Phoenix:

Ich gehe jede Wette ein, dass ich jedes Programm welches Insider2004 in Delphi schreibt, mindestens genauso performant, wenn nicht sogar performanter auf Basis von .NET implementieren kann. Voraussetzung ist, dass zum Vergleich die Sourcen offen liegen - und er sich überhaupt auf die Wette einlässt.

Dass native Code generell schneller sein soll als managed Code ist ein immer wieder propagiertes Gerücht, dass schon zigfach widerlegt wurde, sich aber immer noch hartnäckig hält - und ich will diese verbohrte falsche Annahme endgültig und ein und für alle Male aus der Welt schaffen. Diese Halbwissen und auf seinem (falschen) Standpunkt verharren geht mir so langsam echt derbe auf den Keks.

Edit Nachtrag: Zum Thema Flexibilität: Ich würde zudem darauf tippen, dass ich dazu weniger Code brauche als er und dass mein Code wiederverwendbarer ist - und zudem auch noch auf iOS, Android, Linux, Mac und - dank Cooper - auch auf Java läuft. (Wobei ich auf der Java-Plattform nicht für mehr Performanz garantiere).

Diese Wette brauchen wir gar nicht aufziehen!

.net ist ein zusätzlicher Layer zwischen der Windows API und deinem Prism/C#-Programm. Beim Native-Ansatz greift dein Programm direkt auf die Windows-API zu. Der gesunde Menschenverstand sagt einem, dass die Native-Lösung schneller sein muss (was sie natürlich auch ist).

Jeder Integer und jeder andere Krümmel ist bei .net ein Objekt. Das alles aufzuziehen und hochzufahren braucht unheimlich viel Resourcen (genauso wie bei Java). .net-Programme sind im Schnitt 5-15 Mal langsamer als Native-Programme.

[Bernhard Geyer]

Zitat von Insider2004:

.net ist ein zusätzlicher Layer zwischen der Windows API und deinem Prism/C#-Programm. Beim Native-Ansatz greift dein Programm direkt auf die Windows-API zu. Der gesunde Menschenverstand sagt einem, dass die Native-Lösung schneller sein muss (was sie natürlich auch ist).

Wie hoch ist der Anteil der Rechenzeit auf API-Ebene bei komplexeren Programmen? Und wieviel davon basiert noch auf nativen Win32-Controls? Z. B. jeder der ein großen Tree/Listview mit vielen einträgen benötigt und auf jede ms angewiesen ist wird die Win32-API vermeiden (ElPack, VirtualTreeView, ...)

Zitat von Insider2004:

Jeder Integer und jeder andere Krümmel ist bei .net ein Objekt. Das alles aufzuziehen und hochzufahren braucht unheimlich viel Resourcen (genauso wie bei Java).

Wer in .NET/Java jedesmal wenn er ein skalares int benötigt aber ein Integer-Objekt verwendet (selbst bei Schleifen) ist selbst Schuld. Der sollte sich mit den Grundlagen beschäftigen.

Zitat von Insider2004:

.net-Programme sind im Schnitt 5-15 Mal langsamer als Native-Programme.

Beispiele? Wenn's man richtig macht dann hat man in managed Umgebungen keine Performance oder Ressourcenprobleme. Es existieren einige Fallgruben die man kennen muss (z.B. Stringbuilder statt String-Operationen).