.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, ...)
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.
.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).