Discussion :

[noftal]

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 ?

[wallace1]

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+

[mactwist69]

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.

[noftal]

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.

[clementmarcotte]

Bonjour,

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.

[rv26t]

Bonjour,

As-tu lié les DataGridView à la BDD directement dans le designer avec l'assistant ?

[clementmarcotte]

Bonjour,

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.