WPF vs WinForms Performance in Visual Studio.

Und zwar bin ich auf ein Problem gestoßen, welches mir vorher nie in den Sinn kam: Wenn ich in VS von einer Datei zur anderen wechsle, braucht es 10-15sec.
Das kam allerdings erst, als ich einen großten Anteil von UI-Code implementierte.
(~110.000 lines alleine für UI)[WinForms App]

Ich will gar nicht die Vor- und Nachteile von WPF/WinForms ansprechen, sondern fragen ob jmd ähnliche Erfahrung mit WPF gemacht hat?

Weil es nach einer Zeit doch nervt, wenn man nur 5 Zeilen ändern möchte, aber dafür jedesmal 15 Sekunden warten muss.
Ansonsten kennt einer gute WPF Controls? Falls ich die App wechsle, hätte ich kein Bock alle Controls neu zu schreiben :/

WPF produziert diesen massiven Overhead an Code nicht. Dort hast du lediglich XAML um deine GUI zu "beschreiben" und das ist vergleichsweise gering.

Von WinForms zu WPF wechseln ist übrigens auch keine leichte Sache, da solltest du dich wirklich vorher informieren.

Falls es jmd noch interessiert, es gibt dafür 3 Lösungen:

1) Man lebt damit

2) Man stellt viele Funktionen in VS ab oder nutzt nen lightweight Notepad

3) Man extended seine UI um eine Scripting Language (Hab lua genommen)

WPF ist genauso lahmarschig, wenns um so viele Daten geht. Naja wenigstens etwas dabei gelernt :)

Quote:

Originally Posted by Black Tiger ツ Falls es jmd noch interessiert, es gibt dafür 3 Lösungen: 1) Man lebt damit 2) Man stellt viele Funktionen in VS ab oder nutzt nen lightweight Notepad 3) Man extended seine UI um eine Scripting Language (Hab lua genommen) WPF ist genauso lahmarschig, wenns um so viele Daten geht. Naja wenigstens etwas dabei gelernt :)

WPF ist nicht unbedingt "lahmarschig", kommt nur drauf an, was man damit macht und wie man es macht.

Eine große Hilfe, den Code übersichtlich zu halten und die Dateien möglichst klein zu halten, ist das MVVM Pattern.
Der Sinn dahinter ist, dass man die Logik, die Daten und die tatsächliche UI trennt und nicht hart miteinander verknüpft.
Somit baut man nicht mehr die ganze UI in 1 Datei auf, und hat dann 100k LoC, sondern hat hinterher mind. 2 Dateien.
Model View ViewModel | Wikipedia

Ich weiß ja nicht, was du für eine UI bei 100k LoC hast bzw. was du da noch für eine Logik eingebaut hast, aber im Normalfall kannst du mit WPF ziemlich viel Schreibarbeit sparen. :)
Und spätestens wenn du viel mit Daten arbeitest, die du auf der UI darstellen willst, wirst du DataBinding sehr zu schätzen wissen :handsdown:

Quote:

Originally Posted by Terreox WPF ist nicht unbedingt "lahmarschig", kommt nur drauf an, was man damit macht und wie man es macht. Eine große Hilfe, den Code übersichtlich zu halten und die Dateien möglichst klein zu halten, ist das MVVM Pattern. Der Sinn dahinter ist, dass man die Logik, die Daten und die tatsächliche UI trennt und nicht hart miteinander verknüpft. Somit baut man nicht mehr die ganze UI in 1 Datei auf, und hat dann 100k LoC, sondern hat hinterher mind. 2 Dateien. Model View ViewModel | Wikipedia Ich weiß ja nicht, was du für eine UI bei 100k LoC hast bzw. was du da noch für eine Logik eingebaut hast, aber im Normalfall kannst du mit WPF ziemlich viel Schreibarbeit sparen. :) Und spätestens wenn du viel mit Daten arbeitest, die du auf der UI darstellen willst, wirst du DataBinding sehr zu schätzen wissen :handsdown:

Er wird von MVVM noch nie etwas gehört haben und den WinForms Code Overhead direkt mitgenommen haben. Das dann kein Performance boost in Sicht ist, sollte logisch sein.

Wobei hier eher VS das Problem ist. Bei C++ habe ich nämlich ebenfalls sehr große Performance Probleme wenn ich Boost nutze. Sollte auch logisch sein denn je mehr Code man nutzt und einbindet, desto langsamer wird's auch in der IDE.

Natürlich kenn ich das MVVM pattern und nein ich hab es nochmal neu in xaml mit bindings erstellt. Klar ist die Rendering-Pipeline etwas schneller, aber bei einer dicken Menge wird sie auch extrem lahm, wobei die Modellvorschau des WPF-Designers sowieso noch lückenhaft ist. Natürlich ist damit VS gemeint, aber die UI geht super easy per scripting, muss man nicht mal neu compilern.