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

Die Leistung hängt fast immer davon ab, was du gerade tust.

Wenn möglich, gehe vor Ort und beobachte den Kunden beim Verwenden der App. Finde heraus, wo es zu Verzögerungen kommt, und erstelle dann ein Profil davon - idealerweise mit einer ähnlichen Menge Daten usw.

Überprüfe die Leistung sowohl des Clients als auch des Servers beim Kunden - finde heraus, welcher tatsächlich das Problem verursacht. Überprüfe die Netzwerkkonfiguration und -gesundheit - manchmal können unpassende Einstellungen dazu führen, dass die Dinge funktionieren, aber qualvoll langsam sind.

Answer 2

Das erste, was ich erwähnen muss, ist, dass der .Net-Code niemals in einer VM ausgeführt wird. Auch wenn es stimmt, dass .Net-Programme in IL kompiliert werden, das sich in gewisser Weise mit Javas ByteCode vergleichen lässt, ist der wichtige Unterschied, dass die IL vor dem Start der App vollständig in nativen Code kompiliert wird, anstatt von einer VM interpretiert zu werden.

Über den .Net/VB6-Vergleich. Ich kann keine konkreten Daten angeben, aber aus persönlicher Erfahrung hängt es davon ab, was du tust.

Um das zu veranschaulichen, denken wir an sechs verschiedene Benchmark-Anwendungen, von denen jede eine VB6- und eine .Net-Version hat. Jede Anwendung führt eine spezifische Operation aus, wiederholt sie 100.000 Mal und zeichnet dann die benötigte Zeit auf. Beachte, dass dies ein Gedankenexperiment ist: Ich habe tatsächlich keine Ergebnisse aus echten Apps gesehen. Aber ich habe das Gefühl, die Stärken und Schwächen beider Plattformen zu kennen.

• Anwendung A führt rechenintensive numerische Berechnungen durch. In diesem Fall würde ich vermuten, dass die Ergebnisse hier fast identisch sein werden. Sowohl VB6 als auch .Net werden in nativen Code kompiliert, sodass eine CPU-mult-Anweisung auf beiden Plattformen gleich ist. Das gesagt, wenn du nicht Option Strict verwendest, könntest du auf beiden Plattformen schnell in Schwierigkeiten geraten. Da du C# verwendet hast (was im Grunde genommen immer Option Strict ist), könnte das deinem .Net-Code einen Vorteil verschaffen.

• Anwendung B ruft einen Wert aus einer Datenbank ab. Auch hier sind die Ergebnisse wahrscheinlich sehr ähnlich, aber ich würde .Net einen sehr leichten Vorteil geben, aus zwei Gründen: Es verwendet einen nativen SQL-Client, der angeblich etwas schneller ist, und es führt automatische Verbindungspooling durch und erleichtert das Auslagern von Dingen wie einmaligem Herstellen einer Verbindung und Wiederverwenden dieser Verbindung anstelle von wiederholtem Verbinden. Aber wenn du Äpfel mit Äpfeln vergleichst, was den Code betrifft, werden die beiden wahrscheinlich sehr nah beieinander liegen.

• Anwendung C zeigt und versteckt ein Formular wiederholt. Hier müsste ich VB6 den Vorzug geben. Es basiert auf einem älteren, weniger glanzvollen Widget-Set, das billiger zu rendern sein wird. Außerdem sind die WinForms-Komponenten nicht gerade für ihre Geschwindigkeit bekannt. Allerdings ist der Unterschied wahrscheinlich nicht so groß, wie du denkst, und du wirst wahrscheinlich nicht so oft Formulare vollständig neu zeichnen. Dies ist wahrscheinlich die Langsamkeit, über die sich Ihre Benutzer beschweren.

• Anwendung D basiert auf Zeichenkettenoperationen, und hier muss ich .Net den Vorzug geben. Sowohl VB6 als auch .Net sind für langsame Zeichenkettenoperationen bekannt. Jedoch bietet .Net eine Reihe von Tools, die in VB6 einfach nicht verfügbar sind, um Entwicklern zu helfen, die Langsamkeit zu überwinden. Das gesagt, wenn du diese Tools nicht kennst, könnten schlechte Zeichenketten-Operationen deine App leicht verlangsamen. Auch dies trägt wahrscheinlich zu Benutzerbeschwerden bei.

• Anwendung E wird wiederholt ein XML-Dokument in den Speicher laden. Auch hier denke ich, dass .Net einen Vorteil hätte. Erstens waren die xml-Tools, die für VB verfügbar waren, höchstens primitiv. Ich finde es unwahrscheinlich, dass sie nicht erheblich verbessert wurden. Außerdem ist der Garbage Collector von .Net ziemlich intelligent, was ihm einen Vorteil bei der Zuweisung und Freigabe von Speicher während der Ladevorgänge verschafft. Allerdings denke ich, dass die größte Rolle hier die Geschwindigkeit der Festplatte spielen wird, was bedeutet, dass der Unterschied nicht so groß sein würde.

• Anwendung F wird wiederholt ein .Net- oder VB6-Programm starten, auf dessen Bereitschaft warten (für eine gewisse Definition von "bereit") und dann schließen. Hier hat VB6 wahrscheinlich den Vorteil aus zwei Gründen. Erstens muss das .Net die IL beim ersten Start in Bytecode kompilieren. Glücklicherweise gilt das nur für den ersten Lauf. Zweitens muss die .Net-App auch alle referenzierten Assemblys laden. Im Vergleich dazu ist die VB6-Runtime viel kleiner. Dies trifft jedoch normalerweise nur beim ersten Start der App auf einer bestimmten Maschine zu, und es gibt Möglichkeiten, den .Net-Code vorab zu kompilieren. Dies kann auch zur wahrgenommenen Langsamkeit beitragen.

Ein wichtiger Punkt ist, dass die .Net-App für all diese Anwendungen wahrscheinlich einen viel größeren Speicherbedarf haben wird. Aus irgendeinem Grund neigen Entwickler dazu, dies als eine schlechte Leistungseigenschaft zu betrachten, wenn in Wirklichkeit das Gegenteil der Fall ist. Wenn deine App mehr Speicher verwendet, verbringt sie wahrscheinlich weniger Zeit beim Zugriff auf die Festplatte, und die Festplatte ist bei weitem langsamer. Es wird wahrscheinlich auch mehr zwischengespeichert, was die CPU-Zeit spart. Und speziell für .Net spart es Zuweisungs-/Freigabeoperationen für Zeiten, in denen sie wichtiger sind oder wenn der PC sonst unbenutzt ist.

Ich habe keine Zeit, aber es wäre interessant zu sehen, wie jemand die in Coding Horror des heutigen Tages erwähnte StopWatch-Implementierung (zumindest für die .Net-Seite) verwendet, um echte Benchmarks für jede dieser Anwendungen zu erhalten.

Answer 3

1. Ich habe noch nie nach dieser Art von Daten gesucht. Vielleicht solltest du die kanonische "Pet Shop" -App betrachten, die oft zu Benchmarking-Zwecken verwendet wird. Sie ist wahrscheinlich in beiden Entwicklungsplattformen verfügbar. Ich vermute jedoch, dass es viel wichtiger ist, #2 zu beantworten. Was spielt es schon eine Rolle, ob Pet Shop schnell läuft. Es ist die App deines Kunden, die zählt.

2. Die meisten Leistungsprobleme hängen mit der Datenbank und/oder dem Netzwerk zusammen. Wenn du zwischen den Versionen wesentliche Datenbankänderungen vorgenommen hast, würde ich diese zuerst mit den SQL-Trace-/Profiling-Tools profilieren oder einfach einige einfache Tests auf wichtigen Prozeduren/SQL durchführen, die zur Unterstützung deiner sogenannten "langsamen Performance" ausgeführt werden.

Wenn ich dich richtig verstehe, scheint es bei einigen Kunden in Ordnung zu sein, bei anderen jedoch nicht, und jemand drängt dich darauf, dass es .NET ist und VB6 perfekt war, vielen Dank. Netzwerkunterschiede zwischen den Kunden sind definitiv ein kritischer Unterschied. Server-Betriebssystem, Geschwindigkeit der Switches und Netzwerkinfrastruktur usw. - so viele Variablen zu erkunden. Aber ich würde wetten, dass es nichts mit .NET vs. VB6 zu tun hat.

Answer 4

Ich weiß, dass ich mich in Gefahr begebe, wie der Typ zu klingen, der die Frage in Frage stellt, anstatt sie zu beantworten, aber verstehen Sie, dass ich das komplett im Geiste versuche, hilfreich zu sein.

Im Zusammenhang mit Ihrem größeren Anliegen, dass Kunden sich darüber beschweren, dass die .NET-Anwendung langsamer ist als VB6, überlegen Sie ernsthaft, ob Sie sie zurückkonvertieren möchten, wenn sich herausstellt, dass VB6 tatsächlich schneller ist? Wenn nicht, warum verschwenden Sie dann die Zeit mit Tests?

Auch wenn Sie eindeutig beweisen können, dass Ihre Kunden falsch liegen und .NET schneller ist, gewinnen Sie nichts, indem Sie Kundenbeschwerden ignorieren. Verbringen Sie die Zeit lieber damit, das Problem zu lösen, anstatt die Ursachen zu diskutieren, am Ende werden alle glücklicher sein.

Zuletzt möchte ich darauf hinweisen, dass das Wechseln von Plattformen, um bessere Leistungen zu erzielen, im Allgemeinen keine produktive Angelegenheit ist und in der Regel ein letzter Ausweg von Programmierern ist, die den Plattformkriegen den gesunden Menschenverstand vorziehen lassen. Mein Vorschlag ist, den .NET/VB6-Leistungsvergleich für ein bereits erstelltes Projekt zu ignorieren und stattdessen die Zeit damit zu verbringen, die spezifischen problematischen Bereiche der Anwendung herauszufinden und so gut wie möglich zu optimieren.

Answer 5

Ach, das ist leicht zu sehen. Kopieren Sie 50 Schaltflächen in ein Formular sowohl in WF als auch in VB6 und vergleichen Sie ihre Malgeschwindigkeit nebeneinander. Es ist nicht .NET, das langsam ist, es ist WF, das langsam ist. Ich habe es nie wirklich auf den Punkt gebracht, aber beitragende Faktoren:

• Die Button-Klasse malt wirklich langsam. Sie bittet den Container, den Hintergrund für Transparenz zu malen, den sie nicht hat.
• VB6 hat mehrere fensterlose Steuerelemente, wie z.B. Label. In WF ist jedes Steuerelement ein Fenster.
• Visuelle Stile kommen nicht umsonst.
• Sie haben wirklich hart gearbeitet, um VB1 auf einem 386SUX gut funktionieren zu lassen.