Was ist der beste Weg, um die Leistung von .NET im Vergleich zur Leistung von VB 6 an einer Kundenseite zu vergleichen?

Question

Zwei Fragen:

1. Kann mir jemand Daten nennen, die den .NET-Performance mit der VB 6-Performance vergleichen, ohne Voreingenommenheit? Ich habe gesucht, aber es ist überraschend schwierig zu finden.
2. Was ist der beste Weg, um die .NET-Performance mit der VB 6-Performance zu vergleichen, wenn eine App auf der Seite eines Kunden ausgeführt wird?

Wir haben eine WindowsForms Client-Server-App (geschrieben für 2.0, Upgrade auf 3.5 SP 1 steht bevor), über die sich bestimmte Kunden über "langsame Leistung" im Vergleich zur vorherigen VB 6-Version beschweren. Ich weiß, "langsame Leistung" ist sehr vage und allgemein, aber ist es zutreffend anzunehmen, dass .NET-Code langsamer sein könnte als VB 6-Code, weil .NET in einer virtuellen Maschine läuft? Ich habe 100% des Codes in C# geschrieben, also wurde er nicht von einer dritten Person oder einem Zauberer portiert.

Nicht alle Kunden machen diese Beschwerde, daher vermuten wir, dass etwas Umgebungsbedingt ist. Ist unsere einzige Option, die Leistung an einem Kundenstandort zu messen? Einige unserer Kunden verwenden SQL Server 2005 auf Windows Server 2003 in einem Novell-Netzwerk. Würden sie eine dramatisch unterschiedliche Datenzugriffsleistung als eine ähnliche Maschine in einem Windows-Netzwerk sehen?

Answer 1

Wenn Sie über praktisch die gleiche Client-Anwendung in VB 6.0 und VB.NET sprechen, wird die VB 6.0-App wahrscheinlich schneller zum ersten Bildschirm gelangen (aufgrund der .NET JIT-Kompilierung und Assembly-Ladung). Danach sollte die Leistung ungefähr gleich sein.

Das Problem ist - in jeder realen Situation - würden die Anwendungen unterschiedlich konzipiert werden und ein echter Leistungsvergleich wäre nicht sinnvoll.

Answer 2

Die .Net-Fans haben tausend Ausreden. Zu einem Zeitpunkt hat Microsoft wahrscheinlich aus gutem Grund Vergleiche verboten.

Ein Teil des Grundes, warum .Net langsam ist, ist die Startkosten des Runtimes. Ein Teil davon ist die Zeit, die für das JIT-Kompilieren benötigt wird. Ein Teil davon ist die Garbage Collection. Ein Teil davon ist der Overhead durch den Verbrauch so vieler Speicher, was zu mehr Swapping führen kann. Ein Teil davon ist, dass außerhalb von Inline-Code (das heißt Betriebssystemaufrufe, viele Standardbibliotheken) Thunking durch COM und/oder Win32-Schichten erforderlich ist, um Dinge zu erledigen.

Neuere Maschinen mit viel Speicher und mehreren schnellen CPUs und Festplattengeschwindigkeiten verdecken jedoch einen Teil davon. Das Verdecken macht es nicht weniger verschwenderisch.

.Net war auf die gleichen Dinge ausgerichtet, bei denen Java gut ist. Schnell geschriebener Wegwerfcode und serverseitige Dinge, die lange geladen und ausgeführt bleiben.

Answer 3

Die Leistung gegenüber der VB6-App hängt wahrscheinlich mehr vom Anwendungsdesign ab als von C# gegenüber VB6. Meine Schätzung ist, dass in 9,5 von 10 Fällen die C#-App schneller wäre, wenn sie ordnungsgemäß entworfen würde. .Net läuft nicht in einer VM. Der CLR JIT kompiliert eine .Net-App in Code auf Maschinenebene, was ziemlich schnell ist. Der Grund, warum sie etwas langsamer läuft als nicht verwalteter Code, ist, dass die Sandbox, unter der .Net läuft, verwaltet ist und das hat einige Overheads.