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.
Wunderbar. Fehlt nur noch:
- Lauffähig ab Windows 2000
- Rechner muß mindestens 7 Jahre alt sein und darf nicht mehr als 512 MiB RAM und einen Einkernprozessor haben
- Delphi 2009 oder neuer muß verwendet werden, damit kein unfairer Vorteil aufgrund der Nutzung von ANSI-Funktionen entsteht (die nur Wrapper um die Unicode-Funktionen und damit ein wenig langsamer sind)
- Der gleiche Rechner wird zum Test beider Programme benutzt und frisch vor jedem Testlauf gebootet
Noch dabei?
Oder wolltest du mit deiner Aussage nur nachweisen, daß der durch Caching, Mehrkernprozessoren, mehr billigen
RAM und diverse andere Entwicklungen der jüngsten Vergangenheit stärker herausgearbeitete Flaschenhals des Festplattenzugriffs der eigentlich begrenzende Faktor ist und das native Programm auf einer neueren Architektur irgendwann nur nicht mehr
fühlbar schneller läuft?
Setzen wir doch einfach mal realitätsnahe Bedingungen für den Test an. Außer Entwicklern und Spielern haben viele nämlich noch immer alte PCs. Auch Windows 2000 ist noch verbreitet, wenn uns Entwicklern das auch nicht so lieb sein kann ...
Übrigens, du hast auch nicht gesagt welche .NET-Version zum Einsatz kommen soll! Ich habe das versucht in obige Bedingungen einfließen zu lassen - Windows 2000 sollte hier hinreichend einschränkend wirken.
Akzeptabel?
Nachtrag:
Wenn's man richtig macht dann hat man in managed Umgebungen keine Performance oder Ressourcenprobleme.
Basierend auf welcher Rechnerspezifikation? Mindestanforderungen für, sagen wir, Windows Vista?
Wem die Tricks mit verzögertem Laden des .NET Caches usw. nicht bewußt ist, der braucht nur auf einem XP oder 2003 ein .NET-Programm direkt nach dem Hochfahren zu starten ... und zu waaaarten. Aber ist schon toll, wie dieser Trick immer wieder in den Augen des Publikums funktioniert. Ging bei MS Office auch jahrelang. Bis OOo einen "Schnellstarter" nachgerüstet hat. Bei MS Office war der nur schon seit Jahren drin, so daß die eigentliche Arbeit schon getan war, als der Benutzer glaubte das Programm zu "starten" (welches zu großen Teilen längst im Speicher war).
Und wenn ich die entsprechenden Dienste deaktiviere, sieht es auch nicht mehr so rosig aus. Nur weil in Vista und 7 diese Caches nicht mehr abschaltbar sind, berührt das noch nicht die Gültigkeit der Aussage daß - und hier ist es wo offenbar Phoenix und Insider2004 Äpfel mit Birnen vergleichen - .NET bei eingeschränkter Verfügbarkeit von
RAM und CPU immer (auch fühlbar) langsamer sein wird.
Ich nehme nämlich mal ganz stark an, daß Phoenix hier sehr schnell zurückrudern würde, wenn seine Wette eben mit den o.g. Bedingungen versehen wäre. Dann ist nämlich nicht die Festplatte der
gemeinsame begrenzende Faktor, wie dies bei modernen Systemen meistens der Fall ist, sondern der Speicher und die CPU ...