Geschwindigkeit beim Aufruf diverser Fenster optimieren

  • VB.NET

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Geschwindigkeit beim Aufruf diverser Fenster optimieren

    Guten Tag,

    ich arbeite an einer MDI Anwendung wo der Benutzer mehrere Fenster öffnet und mit diesen arbeitet.
    Manche dieser Fenster haben sehr viele Controls, einige dieser Controls(Combobox, Listbox, Datagrid) müssen auch vorher gefüllt werden und je mehr Controls auf dem Formular vorhanden sind, desto länger dauert der Aufruf des jeweiligen Forms.

    Mein Ziel ist es nun die Geschwindigkeit des Öffnens dieser Forms zu optimieren um einen angenehmeren Fluss zu schaffen.


    Ich habe Fenster die sich in 0,1 Sekunde öffnen, andere Fenster (vielen Controls) brauchen aber 3 bis 6 Sekunden und länger bis diese erscheinen.
    Das ist für den Benutzer natürlich sehr unangenehm und das möchte ich umgehen/optimieren.

    Zu den Fenstern:
    - teilweise befinden sich 50 und mehr Controls, aufteilt in Tabs, auf einem Fenster
    - viele Controls basieren auf Komponenten von Drittanbieter (QIOS, DotNetBar)
    - manche Controls (Combobox, Listbox etc...) werden mit Daten (Datenbank oder Hardcoded) gefüllt. Hier gilt es natürlich das Füllen dieser Controls zu optimieren.


    Gibt es hier grundsätzliche Tipps die man beim Programmieren beachten sollte?
    Ich weiß, das Thema ist sehr variable und offen. Allerdings könnte ich mir vorstellen das viele hier Grundlegende Tipps für mich haben worauf ich in Zukunft achten könnte. Denn mehrere Sekunden zum Aufrufen eines Formulars zu benötigen lässt sich sicherlich optimieren.

    Ich bedanke vorab mich für jegliche Anregungen, Tipps und Fragen :)

    Tja, Patentrezept (ausser halt Wpf) gibts da nicht.

    v.a. muss man genau gucken, wos hängt. Sinds die Forms mit vielen Controls? mit großen Bitmaps? mit Tranzparenz? mit kompliziertem Layout?
    Oder sinds Lade-Vorgänge (da kann zB wpf auch nicht helfen)?

    Jo, und da herumzuoptimieren muß man sich halt auskennen. vlt. hilft ein SuspendLayout, vlt. kleinere Bitmaps nehmen, vlt. Bitmaps cachen, vlt. ListView/TreeView.BeginUpdate() aufrufen, vlt. Databinding deaktivieren, vlt. Fenster nur hiden statt richtig zu schließen, vlt Threading, vlt.....

    Und dann können auch echte Programmierfehler einen Startup ausbremsen, iwas gräuseliges mit Threading, oder abstruse Schleifen, oder hundertmal dieselbe Resource deserialisieren und so Zeugs.

    Und zu guterletzt kanns immer noch sein, dasses einfach nicht besser geht.

    Für den Fall, dass Du Dateien (DBs) auslesen musst, um die Controls zu instanziieren und zu befüllen:
    Hat es Zweck, das Auslesen der Daten bei Programmstart in einem anderen Thread durchzuführen?
    Dort kannst Du z.B. die Daten in DataSets o.ä. ablegen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Vielen Dank für eure Antworten.


    Eistee schrieb:

    WPF wäre wohl die beste Lösung.

    Mit diesem Thema habe ich noch keine Erfahrungen, allerdings habe ich mir gestern einen Artikel dazu durchgelesen.
    Dem entsprechend würde ich es aufgrund von Ressourcen (vor allem Zeitlich) das ganze schon ausschließen müssen. Bei weit über 100 Forms in diesem Projekt bin ich gezwungen bei Windows Forms zu bleiben.


    ErfinderDesRades schrieb:

    Tja, Patentrezept (ausser halt Wpf) gibts da nicht.

    Erwarte ich auch nicht, ich hoffe nur das es ein paar Ansätze gibt die ich mir vielleicht anschauen kann.

    ErfinderDesRades schrieb:


    v.a. muss man genau gucken, wos hängt. Sinds die Forms mit vielen Controls? mit großen Bitmaps? mit Tranzparenz? mit kompliziertem Layout?
    Oder sinds Lade-Vorgänge (da kann zB wpf auch nicht helfen)?

    Es sind sehr viele Controls teilweise. Bitmaps sind vorhanden, meist aber recht kleine Grafiken so das hier vermutlich nicht viel machbar ist zu optimieren.
    Transparenz als Farbe für manche Hintergründe bei Controls sind auch vorhanden.

    Was versteht man unter einem komplizierten Layout?
    So ungefähr sieht eine meiner Masken aus. (siehe Anhang)
    Hinter den jeweiligen Tabs befinden sich natürlich sehr viele weitere Controls für Eingaben, DataGridViews und so weiter.
    Was ich dort optimiert habe ist die Tatsache das ich gewisse "Auswahl-Felder" erst fülle, wenn ich das jeweilige Tab zum ersten mal Anzeige.

    Jedoch dauert das pure Aufrufen der Maske (ohne das füllen von Controls) schon über 3 Sekunden.

    Ich werde mich dann mal mit diversen Anhaltspunkten von dir auseinander setzen, danke für die Begriffe und Ideen.


    RodFromGermany schrieb:


    Hat es Zweck, das Auslesen der Daten bei Programmstart in einem anderen Thread durchzuführen?

    Das ist leider nicht möglich, an diese Idee habe ich auch bereits gedacht. Sobald das Fenster geladen ist werden die gefüllten Auswahl-Felder bereits benötigt.

    Ich bedanke mich
    Bilder

    • form.PNG

      57,1 kB, 797×496, 180 mal angesehen

    wie gesagt: das muß man genau untersuchen.
    zB das Grid scheint mir nicht das Standard-DGV - vlt. ists auch eine dritt-komponente, die laggt.
    oder eben die befüllung - wenn während des Befüllens per Databinding ständig aktualisierungen ausgelöst werden, ... - naja.
    oder auch ColumnheaderSizemode.AllCells kann ein killer sein, weil bei 1000 Datensätzen hat er da viel zu üprüfen.

    eine Optimierungs-Strategie ist Lazy-Loading, man könnte was überlegen mit UserControls auf den Tabs, und dass die erst dann geladen werden, wenn der Tab aktiviert wird.

    aber vorher testen, etwa mal gugge obs schnell lädt, wenn bestimmte Tabs garnet belegt sind und so.

    oder es soll Profiler-Tools geben, mit denen man sowas rauskriegt - k.A.

    Jdfs. die große Gefahr ist, dass du mordsmäßige Umbauten vornimmst, nur um am Ende festzustellen, dasse nix bringen.

    Bevor wir hier rumraten wäre vielleicht hilfreich, wenn Du die Ursache der Ladezeiten mal analysieren würdest: Ursachen kann es , wie schon diskutiert wurde, viele geben. Nimm mal die Stopwatch Klasse und profile mal eines der Fenster mit längerer Ladedauer.

    Weiterhin ist es normalerweise schlechtes Anwendungdesign, wenn selbst 'unsichtbare' Controls/Fenster direkt nach dem Aufruf zur Verfügung stehen müssen. EDS hat das stichwort Lazy-Loading gebracht. Genauso könntest Du diese im Background Thread befüllen und erst nach Vollendung die Tabs freigeben.

    Bibi schrieb:

    Das ist leider nicht möglich, an diese Idee habe ich auch bereits gedacht. Sobald das Fenster geladen ist werden die gefüllten Auswahl-Felder bereits benötigt.
    Das ist mE überhaupt kein Grund: ein Anwender möchte/muss seine Form sofort nach dem Aufruf sehen. Dagegen schadet es nicht wenn man ihm signalisiert, dass noch gearbeitet wird (WaitCursor, Progressbar, Startscreen). Nur sollten die Controls bis zum Abschluss des Ladens disabled sein.

    ErfinderDesRades schrieb:

    wie gesagt: das muß man genau untersuchen.
    zB das Grid scheint mir nicht das Standard-DGV - vlt. ists auch eine dritt-komponente, die laggt.
    oder eben die befüllung - wenn während des Befüllens per Databinding ständig aktualisierungen ausgelöst werden, ... - naja.
    oder auch ColumnheaderSizemode.AllCells kann ein killer sein, weil bei 1000 Datensätzen hat er da viel zu üprüfen.

    Bei dem Grid handelt es sich um ein SuperGrid das an sich schneller arbeitet als ein normales Grid. Aber in diesem Falle spielt es keine Rolle, es wird erst bei Benutzeraktion gefüllt und ist dort auch von der Geschwindigkeit her angenehm, die Spalten werden über einen Spalteneditor (selbst entwickelt) ordentlich gefüllt und in Reihenfolge und Größe dargestellt.

    ErfinderDesRades schrieb:


    eine Optimierungs-Strategie ist Lazy-Loading, man könnte was überlegen mit UserControls auf den Tabs, und dass die erst dann geladen werden, wenn der Tab aktiviert wird.

    Das mache ich bereits, Dinge die auf anderen Tabs zu finden sind werden erst bei "Bedarf" geladen.


    Kangaroo schrieb:

    Bevor wir hier rumraten wäre vielleicht hilfreich, wenn Du die Ursache der Ladezeiten mal analysieren würdest: Ursachen kann es , wie schon diskutiert wurde, viele geben. Nimm mal die Stopwatch Klasse und profile mal eines der Fenster mit längerer Ladedauer.

    Da bin ich gerade bei. Habe diverse Lademechanismen entfernt und bei dem Form mit massig Controls braucht das Anzeigen schon über 3 Sekunden. Nur um die Controls zu zeichnen. Ich vermute das dies vielleicht nicht anders möglich ist wenn man 50 - 100 Controls auf einem Form vorhanden hat.


    Kangaroo schrieb:


    Weiterhin ist es normalerweise schlechtes Anwendungdesign, wenn selbst 'unsichtbare' Controls/Fenster direkt nach dem Aufruf zur Verfügung stehen müssen. EDS hat das stichwort Lazy-Loading gebracht. Genauso könntest Du diese im Background Thread befüllen und erst nach Vollendung die Tabs freigeben.

    Ich werde mich bzgl. dieser Thematik mal einlesen und schauen was da machbar ist.

    Kangaroo schrieb:


    Bibi schrieb:

    Das ist leider nicht möglich, an diese Idee habe ich auch bereits gedacht. Sobald das Fenster geladen ist werden die gefüllten Auswahl-Felder bereits benötigt.
    Das ist mE überhaupt kein Grund: ein Anwender möchte/muss seine Form sofort nach dem Aufruf sehen. Dagegen schadet es nicht wenn man ihm signalisiert, dass noch gearbeitet wird (WaitCursor, Progressbar, Startscreen). Nur sollten die Controls bis zum Abschluss des Ladens disabled sein.

    Einen WaitCursor gibt es natürlich damit der Benutzer weiß das etwas geladen wird. Auch dieser Sache werde ich mal genauer auf den Grund gehen.

    Ich bedanke mich für die guten Ansätze, nun habe ich erst mal ein paar Ansätze denen ich nachgehen kann und bei Erfolg werde ich dies natürlich hier mitteilen.
    Vielen Dank für die super Hilfe :)

    Bibi schrieb:

    Da bin ich gerade bei. Habe diverse Lademechanismen entfernt und bei dem Form mit massig Controls braucht das Anzeigen schon über 3 Sekunden. Nur um die Controls zu zeichnen. Ich vermute das dies vielleicht nicht anders möglich ist wenn man 50 - 100 Controls auf einem Form vorhanden hat.
    Du kannst, während Du Daten in Deine Controls lädtst, deren Update-Mechanismus pausieren lassen:

    VB.NET-Quellcode

    1. MyControl.SuspendLayout()
    2. MyControl.ResumeLayout()
    Das dürfte auch etwas Zeit bringen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende