Leistungskritische GUI-Anwendung (Windows, Linux)

https://stackoverflow.com/questions/9846

08-06-2019
|

Frage

Ich wurde damit beauftragt, eine Reihe von Anwendungen zu aktualisieren, bei denen es sich um leistungskritische VB.NET-Apps handelt, die im Wesentlichen nur Netzwerkstatistiken überwachen und zurückgeben.Ich habe nur drei Anforderungen: Konvertieren Sie es in C#, machen Sie es schnell und stabil

Eine Einschränkung ist, dass wir "Mai" Migration von einer .NET-Plattform zu Linux "bald"

Ich werde in Zukunft für die Wartung dieser Apps verantwortlich sein, daher möchte ich dies richtig machen.Ich habe beschlossen, diese Apps nach dem MVP-Muster umzugestalten, damit ich diesen bösen Jungen ordentlich Unit-Tests durchführen kann.Aber seit ich MVP verwende, dachte ich auch, dass ich die rechenintensiven Aufgaben auch in nativem C/C++-Code erledigen könnte, während die GUI mit .NET Forms oder Qt oder was auch immer erledigt werden würde.

Fragen:

Ist es sinnvoll, eine GUI in Winforms zu erstellen, aber die teuren Dinge in nativem, nicht verwaltetem C/C++?
Gibt es Empfehlungen für ein gutes plattformübergreifendes Fensterkit, das für das oben beschriebene Szenario geeignet wäre?

Lösung

Zunächst einmal würde ich mir etwas Zeit nehmen, um ein paar davon auszuprobieren VB.NET-zu-C#-Konverter.Sie portieren im Grunde die Syntax, und es gibt keinen Grund, dies manuell zu tun, wenn Sie es nicht müssen.Natürlich müssen Sie möglicherweise bereinigen, was aus dem Konverter kommt, aber das ist viel besser als eine manuelle Konvertierung.

Nun zu Ihren Fragen:

1) Ist es sinnvoll, eine GUI in Winforms zu erstellen, aber die teuren Dinge in nativem, nicht verwaltetem C/C++?

Noch nicht.Warten Sie, bis Sie die Konvertierung abgeschlossen haben, und finden Sie dann heraus, wo Sie tatsächlich Ihre Zeit verbringen.Es gibt keinen Grund, C/C++ mit C# zu mischen, bis Sie herausgefunden haben, dass es notwendig ist.Möglicherweise reicht es aus, auf unsicheres C# umzusteigen.Auch das kann unnötig sein.Möglicherweise müssen Sie nur Algorithmen optimieren.Finden Sie heraus, wo Ihre Engpässe liegen und Dann entscheiden Sie, wie Sie sie beheben können.

2) Gibt es Empfehlungen für ein gutes plattformübergreifendes Fensterkit, das für das oben beschriebene Szenario geeignet wäre?

Ich würde es mir ansehen Mono sicher.Das ist wirklich das Beste, was Sie tun können, wenn Sie C# verwenden.Es ist so ziemlich entweder Mono oder eine weitere Umschreibung in einer anderen Sprache, wenn Sie auf Linux umsteigen.

Andere Tipps

1) Vorzeitige Optimierung ist böse.Implementieren Sie Ihre „teuren Dinge“ in C# und prüfen Sie, ob Sie sie umgestalten müssen.Oder richten Sie zumindest einen Test ein, mit dem Sie dies feststellen können.

2) Juch.Plattformübergreifende Benutzeroberfläche.Ich würde mir das „Mai“-Zeug nicht gefallen lassen.Nagelt die Wiesel fest;Wie können Sie Designentscheidungen treffen, ohne zu wissen, was Sie entwerfen?Wenn Sie sich für eine reine .NET-Implementierung entscheiden, werden sie sich dann beschweren, wenn Sie sie (mindestens) umgestalten müssen, damit sie in Mono funktioniert?Wenn Sie es in Java erstellen, werden sie sich dann darüber ärgern, dass es verdammt hässlich aussieht und Benutzer sich darüber beschweren, dass sie ihre .exe-Datei unter all diesen .jars nicht finden können?

1) Nicht unbedingt.Ich denke, es wäre richtiger zu sagen, dass es sich wahrscheinlich lohnt, Ihren Backend-Code in C++ zu schreiben, unabhängig von den Auswirkungen auf die Leistung.Auch wenn Sie Ihre Vorgesetzten nicht an den Plattformwechsel binden können, wäre es ratsam, sich auf diesen Fall vorzubereiten, da Führungskräfte dazu neigen, ihre Meinung oft ohne guten Grund (oder Vorwarnung) zu ändern;Selbst wenn sie sich jetzt dazu entschließen, nicht zu wechseln, heißt das nicht, dass sie sich nicht auch in sechs Monaten für einen Wechsel entscheiden werden.Schreiben Sie Ihre Logik jetzt in C++ und wissen Sie, dass dies eine Möglichkeit ist, auch wenn sie schwieriger ist, aber Ihr Leben später möglicherweise erheblich einfacher machen wird.

2) Nicht wirklich.Es gibt „Lösungen“ wie wxWindows und GTK#, aber oft sind sie fehlerhaft oder schwer richtig zum Laufen zu bringen, oder ihnen fehlt auf der einen oder anderen Plattform etwas Wichtiges.Sie binden Sie normalerweise auch an eine Benutzeroberfläche mit dem kleinsten gemeinsamen Nenner (dh die allgemeinen Steuerelemente funktionieren gut, aber Sie können vergessen, jemals etwas Interessantes – zum Beispiel WPF – damit zu tun).Benutzeroberflächen sind einfach zu schreiben. Wenn Sie Ihre Logik also in etwas Portables schreiben, sollte es meiner Meinung nach eine triviale Angelegenheit sein, mehrere plattformspezifische Benutzeroberflächen zusammenzustellen.

Bei der ersten Frage ist es wirklich schwer zu sagen, ob es sinnvoll wäre, da es wahrscheinlich davon abhängt, welche Art von Leistung Sie benötigen.Ich persönlich habe in richtig gestalteten GUIs mit WinForms keine systemweiten Verlangsamungen aufgrund der GUI gesehen, daher verstehe ich nicht, warum dies zu Problemen führen sollte, und aller Wahrscheinlichkeit nach würde es Ihnen das Leben in Bezug auf die GUI erleichtern .

Was Ihre zweite Frage betrifft: Wenn Sie irgendwann auf eine andere Plattform wechseln möchten, sollten Sie sich die Bibliotheken ansehen, die von Mono implementiert wurden (http://www.mono-project.com/Main_Page), sollte dies auch die meisten Ihrer Anforderungen in Bezug auf plattformübergreifendes Windowing abdecken, da es WinForms und GTK# unterstützt.

Nein, es macht keinen Sinn, die „teuren Sachen“ in C/C++ zu machen.Die potenziellen (und höchstwahrscheinlich geringfügigen) Leistungsverbesserungen überwiegen niemals Ihre Produktivität, was im Vergleich zu C# ein erbärmlicher Witz ist.Wirklich.Es ist nicht einmal annähernd so.

Lesen Sie dies (und alle darin enthaltenen Beiträge) durch:http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Vielleicht möchten Sie die Verwendung in Betracht ziehen Mono.Dies ist eine Open-Source-Version von .NET, die auf vielen Plattformen läuft ... Linux, Mac, Solaris, Windows usw.

Nun zum Codieren Ihrer teuren Sachen in C/C++.Hier ist ein Artikel, der sehr gute Arbeit leistet und die Unterschiede zwischen den Unterschieden erklärt C/C++- und C#-Leistung.

Und ich möchte noch einmal betonen, dass das C++-Zeug wahnsinnig teuer ist.Wäre es sinnvoll, das zu tun, was ich oben erwähnt habe?(.NET-Formulare verbergen schweres C++)

Wie bereits erwähnt, habe ich persönlich keine systemweiten Verlangsamungen aufgrund von WinForms in Anwendungen bemerkt, die sowohl in VB.NET als auch in C# geschrieben wurden.Wenn die Anwendung jedoch wirklich leistungsintensiv ist, kann es zu einer leichten Verlangsamung kommen, wenn Sie alles in C# geschrieben haben, da es in CIL kompiliert wurde (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).Daher wird das Schreiben der GUI in einer Sprache wie C# diesen Teil der Entwicklung wahrscheinlich etwas einfacher machen, sodass Sie mehr Zeit haben, an den kritischen Teilen des Codes zu arbeiten.Der einzige Haken hier ist, dass aufgrund der Aufrufe des C/C++-Codes aus dem C#-Code möglicherweise einige Verlangsamungen auftreten;Dies ist jedoch wahrscheinlich sehr unwahrscheinlich.

1) Ist es sinnvoll, eine GUI in Winforms zu erstellen, aber die teuren Dinge in nativem, nicht verwaltetem C/C++?

Höchst wahrscheinlich nicht.Sofern Sie nicht mit vielen anderen nativen C-DLLs usw. kommunizieren, ist C# wahrscheinlich zwischen 5 % und 5 % langsamer. Schneller als C++ (std::string bringt dich wirklich um, wenn du es verwendest)

2) Gibt es Empfehlungen für ein gutes plattformübergreifendes Fensterkit, das für das oben beschriebene Szenario geeignet wäre?

Wenn es sich nur um einige einfache Formulare mit Schaltflächen handelt, kann Mono diese wahrscheinlich unverändert ausführen.Die Unterstützung für .NET WinForms ist heutzutage ziemlich gut.Es ist allerdings hässlich :-)

Möglicherweise verstehe ich das Problem falsch, aber wenn es sich um ein Netzwerküberwachungssystem handelt, warum ist es dann nicht als „dedizierter“ Windows-Dienst geschrieben?

VB.NET sollte nicht viel langsamer als C# sein.Ich bin mir nicht hundertprozentig sicher, ob es große Unterschiede im generierten IL-Code gibt, aber der einzige Vorteil (und berechtigte Grund, ihn in C# umzuschreiben), den ich mir vorstellen kann (außer, dass C# eine schönere Syntax und einige andere Extras hat). ) ist die Verwendung eines unsicheren Codeblocks, der die Dinge ein wenig beschleunigen könnte.

Das C/C++-Zeug ist vielleicht eine gute Idee, aber im Moment YAGNI.Das Gleiche gilt für das Linux-Zeug.Ignoriere es, Du wirst es nicht brauchen bis du es brauchst.Behalte es einfach.Wie Sie sagen, ist der Unit-Test ein echter Hingucker.Bringen Sie den Code zum Laufen und das Design weiterentwickeln von dort.

Ich hatte vor einiger Zeit ein ähnliches Dilemma, als ich versuchte, den besten Weg zu finden, ein PC-basiertes H/W-Testtool (was offensichtlich „mit UI-Optionen“ bedeutet) zu entwickeln, das mit eingebetteter Hardware interagiert (über eine PCMCIA-Schnittstelle).

Der Engpass bestand darin, dass der Test mit einer maximalen Abweichung von 10 ms von der vom Tester angegebenen vorgesehenen Zeit ausgeführt werden sollte.

Z.B:Wenn der Tester die folgende Testsequenz erstellt:

Die in Schritt 2 genannte Verzögerung sollte nicht > 60 ms betragen.

Ich habe die C++ WIN32-Anwendung als Back-End und VC++ 2005 Winform (.NET-Plattform) für die UI-Entwicklung ausgewählt.Detaillierte Informationen zur Verbindung dieser beiden finden Sie in msdn
Ich habe das System folgendermaßen getrennt:
In VC++ .NET:

In C++ WIN32:

Das komplette System ist betriebsbereit.Es scheint ziemlich stabil zu sein.(Ohne die oben erwähnte Zeitabweichung).
Beachten Sie, dass der von uns verwendete Test-PC ausschließlich für H/W-Testzwecke dient (auf ihm lief nur die Benutzeroberfläche, ohne automatische Updates, Virenscan usw.).usw..).

GTK-Sharp ist ein ziemlich schönes plattformübergreifendes Toolkit.

Gtk# ist ein grafisches Benutzeroberflächen-Toolkit für Mono und .Net.Das Projekt bindet das GTK+-Toolkit und verschiedene GNOME-Bibliotheken und ermöglicht so die vollständig native grafische Gnome-Anwendungsentwicklung unter Verwendung der Mono- und .Net-Entwicklungsframeworks.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow