IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

VB.NET Discussion :

Optimiser un module .designer.vb


Sujet :

VB.NET

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Inscrit en
    Juillet 2013
    Messages
    777
    Détails du profil
    Informations forums :
    Inscription : Juillet 2013
    Messages : 777
    Par défaut Optimiser un module .designer.vb
    bonjour,

    J'ai créé une application Windows Forms.
    Lorsque j'exécute le .exe, cela commence par une Sub Main dans laquelle, je réalise un certain nombre de tâche d'initialisation, puis dans laquelle je lance le formulaire principal par un code du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    f = new FormPrincipal
    SplasScreen.close
    La première instruction de cet extrait de code a pour effet d'exécuter le module FormPrincipal.designer.vb qui est généré automatiquement par l'IDE lors de la conception du formulaire.
    Mon formulaire comporte pas mal de choses sans être, en apparence tout au moins, excessivement complexe : 3 DTG, 3 ou 4 container, 2 groupbox, des barres de navigations et 2 ou 3 barres d'outil.

    Constatant que la séquence de démarrage (= temps écoulé entre le moment où je lance le .exe, et le moment où FormPrincipal apparaît complètement) est assez longue (8s à 20 s selon les ordinateurs testés), j'ai voulu mesurer le temps d'exécution de chacune des procédures et fonctions sollicitées pendant cette séquence.
    J'ai donc créé un petit code qui génère un fichier log.text. Au début de chaque procédure ou fonction appelée, je mémorise dans ce log le nom de la dite procédure ou fonction et la durée écoulée depuis la précédente fonction ou procédure.

    J'ai ainsi pu mettre en évidence que c'est l'instruction f = new FormPrincipal qui rame. En effet, ma séquence de démarrage (que je considère complète lors que mon log fait apparaître la procédure FormPrincipal_Activated) fait à peu près 8 secondes dont 7,5 s rien que pour cette instruction.

    Comme je l'ai indiqué plus haut, cette instruction a pour effet d'exécuter le module FormPrincipal.designer.vb. C'est donc bien ce module qu'il faut que j'optimise.

    J'ai bien réfléchi à distinguer dans ce formulaire les composants dont j'ai vraiment besoin au premier affichage de ceux qui n'ont pas besoin d'être chargés dès le début et à charger ces derniers lorsque j'en ai vraiment besoin. Mais je n'ai trouvé que 2 composants répondant à ce critère. Il s'agit d'un DTG et d'un GroupBox qui sont "masqués" dans le formulaire et qui sont démasqués si je clique sur un certain bouton. Je doute que ces 2 seuls composants change significativement la durée de chargement. Qu'en pensez-vous ?

    Connaissez-vous d'autres astuces ou pistes d'investigation pour optimiser un fichier .designer.vb ?

  2. #2
    Membre Expert
    Avatar de wallace1
    Homme Profil pro
    Administrateur systèmes
    Inscrit en
    Octobre 2008
    Messages
    1 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Administrateur systèmes
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 966
    Billets dans le blog
    7
    Par défaut
    Bonjour,

    Tu ne dois en aucun cas travailler avec le fichier designer.vb directement car il existe tout simplement le moyen d'effectuer des taches à l'issu de l'exécution de la Sub "InitializeComponent()" (initialement prévue pour ça !) depuis ton "FormPrincipal".


    J'ai bien réfléchi à distinguer dans ce formulaire les composants dont j'ai vraiment besoin au premier affichage de ceux qui n'ont pas besoin d'être chargés dès le début et à charger ces derniers lorsque j'en ai vraiment besoin. Mais je n'ai trouvé que 2 composants répondant à ce critère. Il s'agit d'un DTG et d'un GroupBox qui sont "masqués" dans le formulaire et qui sont démasqués si je clique sur un certain bouton. Je doute que ces 2 seuls composants change significativement la durée de chargement. Qu'en pensez-vous ?

    Connaissez-vous d'autres astuces ou pistes d'investigation pour optimiser un fichier .designer.vb ?
    Le fait que des composants soient masqués ne réduit absolument pas le temps de chargement de ton application....je veux dire par là que si tu effectues une routine de remplissage de ton DTG tout le code qui se charge de cela devra être placé dans un thread et si tu veux que ton formulaire s'affiche durant ce laps de temps s'affiche alors il faudra prévoir 1 thread avec délégation pour mettre à jour ton UI.

    Ce n'est pas simple à expliquer d'autant plus que tu ne nous montres pas de quelle manière tu t'y prends concrètement. Sans cela je ne vois pas très bien comment nous pourrions t'aider..car l'implémentation actuelle est très importante pour déterminer ce qu'il serait envisageable de faire pour remédier à ton problème o_O


    A+

  3. #3
    Membre Expert Avatar de mactwist69
    Homme Profil pro
    Développement VB.NET
    Inscrit en
    Janvier 2007
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Saône et Loire (Bourgogne)

    Informations professionnelles :
    Activité : Développement VB.NET
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 707
    Par défaut
    Moi je comprends pas pourquoi le projet ne démarre pas directement sur ta Form principal.
    Tu peux configurer le SplashScreen dans MyProject.

    Et je confirme que masquer des composants ne rends en rien plus rapide le démarrage d'une solution.

    Éventuellement, quand on fait un gros chargement d'un DGV, le temps du chargement on peut stopper son affichage... (Suspend et resume layout)
    Ou une autre astuce est de charger les données dans le constructeur d'une Form plutôt que dans le FormLoad (même principe, il charge et APRES il affiche d'un coup, ca évite les freezes)

    Mais bon... Peut être effectues-tu d'autres traitement (lourd) que tu ne dis pas ?
    Je confirme que le designer, n'est pas censé être touché. Après avoir mis en vrac quelque projets, j'ai arrêté.

    Peut être est-ce ton pc qui est lent également. As-tu compiler ton projet en Release avant de le déployer ?

    Plein de petites choses bêtes, mais beaucoup plus impactant que masquer un contrôle.

  4. #4
    Membre éclairé
    Inscrit en
    Juillet 2013
    Messages
    777
    Détails du profil
    Informations forums :
    Inscription : Juillet 2013
    Messages : 777
    Par défaut
    Citation Envoyé par mactwist69 Voir le message
    Moi je comprends pas pourquoi le projet ne démarre pas directement sur ta Form principal.
    Je ne me souviens plus. Il y avait une raison qui avait d'ailleurs fait l'objet d'un topic de ma part. Cela remonte à loin. Mais de toute façon, ce choix n'est pas la cause de la lenteur.


    Et je confirme que masquer des composants ne rends en rien plus rapide le démarrage d'une solution.
    Je n'ai jamais prétendu le contraire. C'était juste pour expliquer que, à la rigueur, je pourrais optimiser en chargeant ces 2 composants ultérieurement, c'est-à-dire au moment où je commande leur affichage.
    La question était d'avoir votre avis sur la probabilité que j'en tire un gain suffisant en temps. Parce que si c'est pour gagner 300ms sur les 7000 ms, je ne vais pas m'embêter.


    Ou une autre astuce est de charger les données dans le constructeur d'une Form plutôt que dans le FormLoad (même principe, il charge et APRES il affiche d'un coup, ca évite les freezes)
    Encore une fois, ma lenteur s'explique par le chargement du form AVANT que la sub Form_load soit attaquée. J'ai beaucoup de choses dans le Form_load, mais mon outil de trace montre que 1°/ ces routines s'effectuent malgré tout très rapidement, 2°/ les 7s observés, c'est avant le début du load


    Mais bon... Peut être effectues-tu d'autres traitement (lourd) que tu ne dis pas ?
    Je confirme que le designer, n'est pas censé être touché. Après avoir mis en vrac quelque projets, j'ai arrêté.

    Peut être est-ce ton pc qui est lent également. As-tu compiler ton projet en Release avant de le déployer ?
    Bah c'est un i5, mais j'ai effectué le test sur deux i7 différents :
    - l'un est mon portable pro : le chargement est effectivement très rapide
    - l'autre est la bête de course d'un pote : son chargement est beaucoup plus long !!
    Je n'ai pas réussi à trouver de relation de cause à effet entre ces différents comportements

    Sinon, oui, j'ai bien compilé en mode release.

    Plein de petites choses bêtes, mais beaucoup plus impactant que masquer un contrôle.
    On s'est mal compris mais avec ce que j'ai écrit plus haut, je pense que tu as compris que je n'ai pas masqué le contrôle pour gagner du temps.
    L'idée que je vous exposais consistait à faire ceci :
    - copier/coller le code du designer.vb relatif aux 2 composants (en faisant gaffe de ne rien oublier...) dans un fichier texte provisoire
    - supprimer ces 2 composants en mode design
    - recopier le code copié au point 1 dans la routine du bouton_click qui a pour effet, dans mon appli, de démasquer ces 2 composants.
    Cela reviendrait à créer dynamiquement ces 2 composants au moment précis où j'en ai besoin pour, en contrepartie, faire baisser la durée de l'initialisation du form principal qui aurait donc 2 composants en moins à charger, et augmenter la durée d'exécution du bouton_click. La question est de savoir si la différence serait sensible.

    Pour illustrer complètement mon propos, voici l'extrait du log depuis le début jusqu'au Form_load.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Date début	Durée	Cumul	Proc/fonction
    16406952	0	0	Main
    16407061	109	109	InitialiseDB
    16407061	0	109	CheckVersionAtStartAndInstall
    16407061	0	109	IsAutomaticUpdateChecked
    16407093	32	141	IsDBValid
    16407264	171	312	CultureInfoToDB
    16407280	16	328	juste avant le f = New FORM_Principal
    16414378	7098	7426	juste après le f = New FORM_Principal
    16414534	156	7582	FORM_Principal_Load
    Vous voyez que je passe de t=328 ms à t=7426ms juste en lançant l'instruction f= new FORM_Principal. et vous voyez aussi que le FORM_Principal_Load est attaqué à t=7582ms donc après.

  5. #5
    Inactif  

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2012
    Messages
    4 903
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 68
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : Janvier 2012
    Messages : 4 903
    Billets dans le blog
    36
    Par défaut
    Bonjour,


    Citation Envoyé par noftal Voir le message


    Encore une fois, ma lenteur s'explique par le chargement du form AVANT que la sub Form_load soit attaquée.
    J'ai constaté (depuis VB 2010, je pense) que ce phénomène peut se produire quand il survient une erreur dans le code avant l'appel "officiel" de la Form. La Form va s'afficher sans prévenir, sans message d'erreur et sans exécuter le Form_Load.

  6. #6
    Modérateur

    Homme Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 722
    Par défaut
    Bonjour,

    As-tu lié les DataGridView à la BDD directement dans le designer avec l'assistant ?
    Traductions d'articles :
    La mémoire en .NET - Qu'est-ce qui va où ?
    Architecture DAL de haute performance et DTO ; Version C# : Partie 1,Partie 2,Partie 3 — Version VB.NET : Partie 1,Partie 2,Partie 3
    N'hésitez pas à consulter la FAQ VB.NET, le cours complet de Philippe Lasserre et tous les cours, articles et tutoriels.

  7. #7
    Inactif  

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2012
    Messages
    4 903
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 68
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : Janvier 2012
    Messages : 4 903
    Billets dans le blog
    36
    Par défaut
    Bonjour,

    Citation Envoyé par wallace1 Voir le message
    Bonjour,

    Tu ne dois en aucun cas travailler avec le fichier designer.vb directement car il existe tout simplement le moyen d'effectuer des taches à l'issu de l'exécution de la Sub "InitializeComponent()" (initialement prévue pour ça !) depuis ton "FormPrincipal".
    Ça, je suis bien d'accord. Encore que j'ai déjà dû "désobéir" pour l'empêcher de brailler et s'arrêter avec le message "Ce formulaire ne peut pas s'afficher"; à cause d'un contrôle "perdu" au cours des années.

Discussions similaires

  1. optimisation de design
    Par lipaika dans le forum Optimisations
    Réponses: 2
    Dernier message: 19/06/2008, 19h38
  2. Réponses: 2
    Dernier message: 01/04/2008, 22h35
  3. Design Pattern pour module de raisonnement
    Par befalimpertinent dans le forum C++
    Réponses: 6
    Dernier message: 18/06/2007, 21h46
  4. [Designer 10g] Comment faire un lien entre module
    Par Gouzoul dans le forum Oracle
    Réponses: 1
    Dernier message: 21/04/2006, 11h27
  5. [Designer] Problème de transfert de données entre modul
    Par BILLYPATOU dans le forum Designer
    Réponses: 11
    Dernier message: 09/03/2004, 18h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo