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,

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.

[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 ?

[noftal]

Oui.
J'ai mis en DataSource de mes DTG des bindingsources qui ont été "déposés" dans le cadre des composants du formulaire en mode design avec la boite à outil.
Et mes BS ont comme DataMember les Datatables de ma BdD
Pourquoi ?

[noftal]

Je relance un peu le sujet car sur le fond je n'ai pas trouvé la solution à ma problématique évoquée dans le premier message mais j'ai un peu progressé dans le sens où je ne suis pas sûr que le .designer.vb de mon form principal soit en cause.

Nota : rv26t, si tu peux me dire ce que tu avais derrière la tête, ta question me laisse entendre que tu as peut-être une idée

En fait, j'ai regardé de vieilles version de mon application. Je suis remontée à l'une d'elle, pas si ancienne où l'instruction f = new FormPrincipal est exécuté en 700 ms au lieu de 7000 ms pour la dernière version (durée mesurée de manière précise à l'aide d'un timer)

Comme je l'ai dit, je sais que cette instruction lance le code .designer.vb du formulaire. J'ai donc comparé les codes de ce fichier pour les 2 versions.
Il se trouve que ces 2 versions sont très similaires. Certes j'ai modifié mon formulaire entre les 2. Mais en terme de nombre et de nature de composants, c'est quasiment pareil. L'imbrication des composants entre eux n'est pas tout à fait la même mais, en couchant l'arborescence de ces composants, j'en viens même à dire que c'est la version la plus véloce qui est la plus compliquée en termes d'imbrication.

Toute la journée, j'ai cherché du côté du XSD. J'imagine que son architecture doit être lue également lors de l'instruction f= NeW FormPrincipal encore que je n'en sois pas sûr.
Là aussi, échec. Il se trouve que, en théorie, son contenu est identique entre les 2 versions. Pour voir s'il n'y aurait pas un bogue dans la génération automatique du code associé à ce fichier, j'ai recopié les fichiers XSD, XSC et XSS de la version rapide dans le répertoire de la version lente.
Cela n'a strictement rien changé à la vitesse de cette dernière.

Je ne sais plus où chercher. La question n'est donc plus tant d'optimiser le fichier .designer.vb puisque la comparaison entre les 2 versions montre qu'il est à peu près identique, mais de savoir où investiguer pour comprendre les différences de vitesse entre les 2 version pour la seule exécution du f = new FormPrincipal

Je rappelle que le formPrincipal_load est hors de cause puisqu'il n'est pas exécuté lors du f= New FormPrincipal mais lors du Application.Run(f) qui intervient plus tard dans mon code.

Merci d'avance pour votre aide.

[wallace1]

Bonjour,

Ta classe FormPrincipal possède-t-elle un initialiseur personnalisé du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Public Sub New
    InitializeComponent()
    '......
    '.........
    '.............
End Sub

Si oui quelles procédures sont lancées dans le corps de cette Sub ?

PS : Si tu ne veux pas poster en public ton projet ou bien ta source partielle est-il possible par MP de voir le contenu de ta Sub Main ainsi que ta classe FormPrincipal stp ?


A+

[noftal]

Bonjour,

Bizarrement, mon .designer.vb qui déclare la classe FormPrincipal ne comporte pas de sub new

Je t'envoie le fichier en MP

EDIT : j'ai retrouvé la sub new...
Comme j'étais dans "D2clarations", je ne risquais pas de la trouver
Donc pour répondre à ta question : je n'ai rien d'autre que InitializeComponent() dans la sub new

[noftal]

Précédemment, j'écrivais :

En fait, j'ai regardé de vieilles version de mon application. Je suis remontée à l'une d'elle, pas si ancienne où l'instruction f = new FormPrincipal est exécuté en 700 ms au lieu de 7000 ms pour la dernière version (durée mesurée de manière précise à l'aide d'un timer)

Cette différence de vitesse que je cherchais à expliquer, sans succès jusqu'ici a peut-être une explication.

Je viens de me rendre compte que l'ancienne version était exécutée en mode Debug. J'obtiens alors le log performance qui suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Date début    Durée    Cumul    Proc/fonction
0001610897    0    0    Main
0001610991    94    94    InitialiseDB
0001611006    15    109    IsDBValid
0001611147    141    250    CultureInfoToDB
0001611162    15    265    avant designer
0001612020    858    1123    après designer

Si je passe en mode Release dans Visual Studio, et si je lance ensuite l'exécution de l'appli, j'obtiens ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Date début    Durée    Cumul    Proc/fonction
0001710753    0    0    Main
0001710862    109    109    InitialiseDB
0001710878    16    125    IsDBValid
0001711018    140    265    CultureInfoToDB
0001711034    16    281    avant designer
0001718195    7161    7442    après designer

J'ai mis en rouge la ligne importante.

On voit qu'en mode release, je retombe sur une durée de 7000ms soit l'équivalent de ce que j'ai avec ma dernière version d'appli (qui elle, est bien testée en mode Release).

J'ignorais que le mode Release et le mode Debug puissent avoir de telles différences de rapidité. A vrai dire, je n'ai jamais trop étudié les différences fondamentales entre ces 2 modes. Jusqu'ici, j'ai appliqué bêtement ce que me disaient les tutos : Développer en mode Debug, Publier en mode Release. Pour tout dire, depuis que je publie mon appli, je développe les nouvelles versions en mode Release. C'est dire si je ne capte vraiment pas les subtilités.

Est-ce que cela vous paraît évident que le mode Debug puisse être plus rapide pour l'initialisation d'un formulaire que le mode Release ? A priori, j'aurais cru l'inverse.

[wallace1]

Salut,

Voilà ce que j'ai pu trouver concernant les differences entre le mode Debug et Release :


http://www.hanselman.com/blog/Releas...allStacks.aspx

http://www.hanselman.com/blog/DebugV...othWorlds.aspx




J'avoue en découvrir encore davantage sur JIT en ayant lu ces billets....

++

[Pol63]

le mode debug est plus lent que le mode release, il aide à mieux débugger, permet de modifier le code pendant l'exécution etc...

concernant le problème, ce n'est pas les controles qui mettent 7 secondes à se créer, vous avez donc du code qui est long dans le code généré
si vous avez des datasets ou autre, alors c'est le temps de lecture de la base de données qui est long et inclus dans le code
vous pouvez faire du debug dans la sub initiliazecomponent genre rajouter des chronométrages
(par contre ce code sera effacé à la prochaine mise à jour de l'UI car le fichier .designer est regénéré comme dit précédemment)

quand on a quelque chose qui prend plus d'une seconde, en général on le déporte sur un thread, l'utilisation des assistants de données de visual studio n'est pas vraiment compatible avec ca
quand on code tout soit même on est forcément plus libre

[Kropernic]

le mode debug est plus lent que le mode release, il aide à mieux débugger, permet de modifier le code pendant l'exécution etc...

Sauf que ici, c'est apparemment l'inverse...

[noftal]

Sauf que ici, c'est apparemment l'inverse...

J'ai lu les liens de wallace1. Ca dépasse un peu mes compétences mais je crois en retirer que, contrairement à ce qu'on a coutume de dire,
- il est des situations (difficiles à identifier) où le mode Release peut être plus long que le mode Debug
- il n'y a pas de contre-indications à publier une appli en mode debug.

Il faut que je vérifie le reste du fonctionnement de mon appli en mode debug, mais je suis assez tenté par cette solution. Le .exe ne fait que 100 ou 200 ko de plus seulement en mode debug. Et si cela me permet de gagner 6s au démarrage sans que le reste de l'appli ne voie sa performance détériorée, n'est-ce pas la meilleure solution ? Y verriez-vous d'autres objections ?

Bien sûr, il y a la méthode préconisée par Pol63. Mais c'est quand même beaucoup plus compliqué !

[wallace1]

.....
......
.........
Bien sûr, il y a la méthode préconisée par Pol63. Mais c'est quand même beaucoup plus compliqué !

Personnellement je n'ai jamais eu l'habitude de livrer en compilant depuis le mode debug c'est pourquoi j'opterais avec insistance (comme mentionné dans ma 1ère intervention) pour des liaisons dynamiques depuis un thread de toutes les phases qui nécessitent des calculs longs.....
Je ne dis pas que c'est la meilleure solution......à voir ce qu'en pensent les autres membres, j'aime ce genre d'échanges très constructifs.

++

[Kropernic]

A moins que j'ai loupé un truc, il ne semble pas y avoir de longs calculs effectués.

Sinon ils le seraient également en mode debug et pas uniquement en release (à moins que la DB cible ne changent également et qu'il y ait plus de choses à charger mais je ne pas que noftal soit du genre à passer à côté de ce genre de choses évidentes).

Personnellement, je ne développe que des applications internes et je n'utilise jamais le mode release. En fait, je l'ai fait au début puis un jour, j'ai oublié. Je me suis rendu de l'oubli quelques temps plus tard en constatant que tout avait parfaitement bien fonctionné. Du coup, je ne m'emmerde plus. D'autant plus que je suis prêt à parier que mon collègue ne sait même pas que ce mode existe...

[wallace1]

A moins que j'ai loupé un truc, il ne semble pas y avoir de longs calculs effectués.

Sinon ils le seraient également en mode debug et pas uniquement en release (à moins que la DB cible ne changent également et qu'il y ait plus de choses à charger mais je ne pas que noftal soit du genre à passer à côté de ce genre de choses .....
......
.........

En effet, il n'y a pas de phases de long calculs mais en lisant les billets postés supra j'aurais tendances a dire qu'il y a certainement qqch dans le designer qui fait que JIT fait des siennes lors de la compilation en mode release. Ce qui est dû à la soit disante optimisation du code...... donc en ayant parcouru les fichiers de noftal je considère à ma facon que les phases de liaisons (présentes en bon nombre) au DTG depuis un dataset correspondent a cette longue phase de calculs......
En fait j'avoue c'est assez bizarre comme comportement...car rien ne saute aux yeux.......é______è

Cdlt

[noftal]

Comme le dit Kropernic, je ne vois pas très bien ce que je pourrais mettre dans un thread séparé dans le cas qui est le mien.
Rappelons que c'est le f=new form qui affiche des temps très longs en mode release. Il n'y a donc pas de calculs particuliers. Les instructions correspondantes correspondent sans doute à tout le code du fichier .designer.vb et éventuellement (mais c'est assez nébuleux j'avoue) au temps d'accès à la base de données. Comme l'affichage de ce form est le point de départ de l'utilisation de l'appli, il faudra bien que j'attende son affichage pour pouvoir faire quoique ce soit d'autre.
Je note que Kropernic semble ne pas avoir d'objection à publier en mode Debug.
D'autres avis ?