Laden...

Geschwindigkeit von WPF und WinForms messen: Was ist schneller?

Erstellt von 4dk2 vor 4 Jahren Letzter Beitrag vor 4 Jahren 2.251 Views
4
4dk2 Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren
Geschwindigkeit von WPF und WinForms messen: Was ist schneller?

Moin,
in dem https://www.mycsharp.de/wbb2/thread.php?threadid=122489
ist es aufgekommen, dass WinForms grundsätzlich nicht langsamer ist als WPF 😁

Ich mag persöhnlich WinForms lieber als WPF, hab auch eigendlich eher ungern mit GUI zu tun. Aber WPF ist zumindest meiner meinung nach schneller
Vor einiger Zeit schon, hab ich aber mal den Test im Vergleich gemacht.

Im Anhang ist das Projekt, straft mich bitte nicht wenn das einiges einfacher gegangen wäre, unsauber aussieht oder sonstwas. Es War ein Test, kein Projekt 😉

Prinzip des Projekts:
Eine gemeinsame Lib für Forms und WPF.
-AppWPF startet den Test unter WPF (kann aber auch den Test für Forms Starten und messen)
-AppForms startet den Test unter Forms (kann aber auch den Test für Wpf Starten und messen)

Es werden unterschiedliche Zeiten gemessen.
Die Haupt Routine ist TestThread.Worker_DoWork(), dort findet der Testablauf statt.
Beim messen bin ich mir nicht 100%ig sicher ob es akkurat ist. Bzw ob es ne andere Möglichkeit gibt, festzustellen wenn WPF/Forms mit dem "GUI-Update" fertig ist.

Aktuelles Prinzip:
Im Thread die Interface-Funktionen aufrufen, die werden dann per BeginInvoke() Synchronisiert.

Danach wird im Thread gewartet bis alle Invokes abgeschlossen sind.
So wird nach Beendung des "Draw" die zeit gestoppt

Bei meinem PC mit 4.7.2. komme ich auf die Zeiten:
WPF: 8ms~
Forms: 30ms~

Wichtig ist! Forms und WPF gleichzeitig (ist im Test ja möglich) verfälscht die Ergebnisse.
Sobald ein WinForms.Form aktiv ist, geht die Zeit von WPF auf die vom Forms.
Also separat testen.

Was meint Ihr ist der Test überhaupt so relevant? Verbesserbar?
Bin da Offen 😉

while (!_terminate)
            {
                if (!Pause)
                {

                    if (TestSwitches.TraceAccessStack)
                        Trace.WriteLine("MAINLOOP Start");


                    var tcid = Tools.Timings.Start(GetGroup(),"Thread LOOP");
                    foreach (var c in _TestControls)
                    {
                        if (c is ITestInterface)
                        {
                            ITestInterface view = (ITestInterface)c;

                            if (view.UpdateViewCounter() > 0)
                            {
                                if (TestSwitches.Trace)
                                    Trace.WriteLine("UpdateViewCounter>0?????? sollte nicht passieren!");

                                Thread.Sleep(100);
                                continue;
                            }
                            view.Begin_UpdateView();
                            view.UpdateView();
                            view.End_UpdateView();
                        }


                        //WaitV2();
                    }

                    WaitAllEndUpdate(); //so wird gewartet bis alle views EndUpdate() gemeldet haben 

                    if (TestSwitches.TraceAccessStack)
                        Trace.WriteLine("MAINLOOP End");


                    Tools.Timings.Stop(tcid);

                }//pause
                Thread.Sleep(TestSwitches.ThreadPauseMs);
            }
5.657 Beiträge seit 2006
vor 4 Jahren

Was meint Ihr ist der Test überhaupt so relevant?

Absolut irrelevant. Ob eine Darstellung schneller ist oder nicht, hängt von so vielen Dingen ab: Welche Controls verwendet werden, welche und wieviele Daten angezeigt werden, die Art der Daten-Aufbereitung, die Art der Darstellung (Hardwarebeschleunigung oder nicht), CPU, Grafikkarte, Grafiktreiber usw.

Wenn du eine konkrete Aufgabe hast, die zu langsam ist, dann kannst du dich an die Suche nach der Ursache machen. Aber was du machst, ist kein Kriterium für die Entscheidung für eine UI-Technologie.

Weeks of programming can save you hours of planning

16.807 Beiträge seit 2008
vor 4 Jahren

Da liege ich mit der Aussage, dass der Code "suboptimal" ist, gar nicht mal so falsch.
Solche Herangehensweisen führen genau dazu, dass aus einem Minifall eben pauschale Aussagen werden, darunter

  • C# ist langsamer als C++
  • WinForms ist langsamer als WPF

.. die andere für Wahr nehmen und das weiter verbreiten.

  1. so misst man keine Performance; vor allem nicht mit anghängtem Debugger
  2. Thread.Sleep ist ungau und verfälscht jegliche Testergebnisse

Ansonsten: der gesamte Test ist irrelevant, weil die gesamte Performance von viel mehr Faktoren abhängt.
Basierend auf der Sache hier ist die Aussage halt einfach nur "Fake News". ⚠

Aber WPF ist zumindest meiner meinung nach schneller

Einfach mal Google verwenden und lesen.
Dann wirst Du sehen, dass stabile Tests belegen, dass es auf die Situation ankommt, was schneller ist - und was nicht.

Dir kann man aber ans Herz legen, nachdem Du hier zwei Threads mit fragwürdigen Performance-Aussagen in kürzester Zeit hast, dass Du Dich bitte zuerst mit solchen Dingen beschäftigst, bevor eben solche Halbwahrheiten verbreitet werden.
Du hilfst damit niemanden, schadest aber vielen.
Danke 👍

4
4dk2 Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren
  1. so misst man keine Performance; vor allem nicht mit anghängtem Debugger

ich hab das ohne Debugger getestet.

  1. Thread.Sleep ist ungau und verfälscht jegliche Testergebnisse

was wär die alternative? und außerdem hab ich den Test nicht einmal gemacht, sondern über 1000 Iterationen.

Ansonsten: der gesamte Test ist irrelevant, weil die gesamte Performance von viel mehr Faktoren abhängt.
Basierend auf der Sache hier ist die Aussage halt einfach nur "Fake News". :]

Klar gibt immer irgendwelche Faktoren, die dann dem andern Framework zuspielen können.
Wenn zwei Autos nen 1/4 Meilen Renn machen, kann man auch sagen "ja gut, das Verlierer Auto, hat mehr Drehmoment und wäre mit mehr Traktion durch Zwangsbeladung beider, dann schneller"

Aber WPF ist zumindest meiner meinung nach schneller
Einfach mal Google verwenden und lesen.
Dann wirst Du sehen, dass stabile Tests belegen, dass es auf die Situation ankommt, was schneller ist - und was nicht.

Joar dann google mal nach aktuellen Tests. Und nicht was das 5 jahre alt ist.
Weil ich vermute mal, dass Winforms dann leider schlechter abschneiden würde.
In der 4.7.2 ist glaub ich ordentlich was passiert. Vor nem halben Jahr hatte ich noch deutlich andere Werte

Dir kann man aber ans Herz legen, nachdem Du hier zwei Threads mit fragwürdigen Performance-Aussagen in kürzester Zeit hast, dass Du Dich bitte zuerst mit solchen Dingen beschäftigst, bevor eben solche Halbwahrheiten verbreitet werden.
Du hilfst damit niemanden, schadest aber vielen.
Danke 😮

Das man nie eine Komplett Aussage treffen kann, sondern nur auf einen Teilbereich weiss ich auch.
Aber was ist 90% von dem was in beiden Fällen Genutzt wird?
Buttons, Labels, Grids, Textboxen.
Und Vollwahrheiten wird hierzu wohl keiner abgeben können.

Und statt drauf einzugehen, "ok, dies und das könnte man machen, dann holt winforms auf" wird lieber auf die politsche Korrektheit geschaut.
Und deine beiden angeführten Punkte sehe ich nun nicht als Knackpunkt

16.807 Beiträge seit 2008
vor 4 Jahren

Es gibt prinzipiell keine Alternativen zu Sleep, denn die Technik dahinter ist einfach ungenau.
Das liegt an der Auflösung der Timern von Betriebssystemen. Jegliches Executing Pausing ist "schlecht", ungenau und sollte immer, wenn möglich, vermieden werden.
Siehe auch Thread.Sleep is a sign of a poorly designed program.

Es gab in .NET auch keine großen Änderungen bei WPF oder WinForms - auch nicht bei .NET 4.7.2. Die Änderungen sind öffentlich; les es Dir durch.
WinForms verwendet eben GDI und WPF vor allem Direct3D. D.h., dass Windows selbst dahingehend aktualisiert werden müsste, da .NET eben nur die Betriebssystem-Schnittstellen verwendet.
Daher hat WPF auch riesen Vorteile bei Systemen mit einer GPU; aber halt auch nicht immer. Und bei Systemen ohne GPU wird eben alles über die CPU gerendert, und dann siehst für WPF nicht mehr ganz so rosig aus.
Schau Dir bitte das Zeug an, bevor Du haarsträubende Vergleiche baust 🙂

Du kannst Dich jetzt an den Fakten orientieren, dass so ein Vergleich einfach total hinkt - oder halt mit der Pauschalität weiter machen.
Letzteres ist halt einfach unseriös; und unwahr.

Davon abgesehen ist WPF an für sich schon allein wegen MVVM die "bessere Technologie".
Aber die pauschale Aussage, dass WPF immer schneller sei, ist einfach falsch. 😉

4
4dk2 Themenstarter:in
12 Beiträge seit 2018
vor 4 Jahren

Der Beitrag zu Thread.Sleep(..) ist von 26.04.2007. weiss nicht ob das noch zeitgemäß ist.
Ich werds durch Task.Delay() ersetzen. Ist ja mit 4.5 eingeführt worden und sollte zeitgemäß sein.

In 4.7.2 scheinbar nicht aber in 4.7 wurden für HIGH DPI Anpassungen gemacht. Maybe thats the reason 😉

Du hast dich da falsch ausgedrückt. Ich hab das noch nie gesehen 🤔
Du meinst wohl ein System, was keine GPU mit Direct3D Unterstützung hat.
Ich werds mal in der VMware ohne Direct3D testen. Sollte ja dem am nächsten kommen.

Du hast "bessere Technologie" gesagt. Ich glaube das ist eine pauschale Aussage. Ich habe nicht gesagt es sei immer schneller, und auch das es meiner Meinung entspricht, und Fakten für meine Meinung hinterlegt, die es im aktuellen Beispiels-Fall stützen.
Einen Link zur Widerlegung hab ich bisher nicht gesehen. Nur Allgemeinheiten.

463 Beiträge seit 2009
vor 4 Jahren

@4dk2:

Nur als Hinweis von meiner Seite - du schreibst ziemlich viel, sagen wir mal so, wirres Zeug und vergleichst permannent, wie Abt es auch schon mehrfach geschrieben hat - Äpfel mit Birnen.

Was willst du eigentlich sagen/beweisen?

Ich achte bei meinen Programmen lieber darauf, dass alle Hintergrundtasks sauber und schnell arbeiten - sobald es aber um eine GUI Ausgabe geht ist es mir ehrlich gesagt egal ob es nun 40ms oder 800ms dauert bis die Anzeige steht... Solange der User keine Beeintrachtigung bzw. Wartezeit von mehr als 1 Sekunde hat, mache ich mir darüber überhaupt keine Gedanken.

Stefan

6.911 Beiträge seit 2009
vor 4 Jahren

Hallo 4dk2,

Der Beitrag zu Thread.Sleep(..) ist von 26.04.2007. weiss nicht ob das noch zeitgemäß ist.

Ja ist er.
Betimmte "Dinge" werden so gut wie nie obsolet.
V.a. für Thread.Sleep gibt es mehr als genug bessere Alternativen, die einen Thread nicht einfach schlafen lassen -- dazu sollten Threads einfach nicht verwendet werden, da diese zum Arbeiten da sind.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"