Discussion :

[takinelinfo]

Bonjour,
J'ai une petite question concernant mon application WPF.
Je me suis rendu compte que quand je suis sous Visual Studio et que je lance mon application, j'ai deux processus qui se lancent:
- FrameworkService.exe
- WPFFontCache_v0400.exe

1) Est ce que si je build ma solution en "Release" et que je l'exécute sur une autre machine ces processus se lancent?

J'ai vu qu'il y a une sacrée différence entre un démarrage à chaud et un démarrage à froid.
2) D'où est ce que ça vient, n'est il pas possible de simuler un démarrage à chaud. Je ne sais pas, soit en installant un service, soit en lançant automatiquement un .exe
Est il possible de gagner du temps à ce niveau là svp.
Merci beaucoup.

[GuruuMeditation]

Il y a plusieurs façons :
- Utiliser NGEN (ça évitera déjà le temps JIT)
- Optimiser les initialisations des fenêtres (Voir si il y a des choses qui peuvent être initialisées plus tard, style Webservice, chargement de ressources, etc...)
- Mettre un Splashscreen

En relation avec les points 2 et 3, la sensation de vitesse est plus importante que la vitesse elle-même. Si, en jouant avec des splashscreen et en affichant la 1ere fenêtre plus vite en mettant des initialisations plus tard (déplacer le problème quoi), ça va plus lentement mais que l'utilisateur à l'impression que ça va plus vite, c'est ce qui compte.
Beaucoup de principes UX sont basé sur cette affirmation (Je ne charge que la moitié des données => je démarre plus vite => l'utilisateur pense que l'appli tourne plus vite (en simplifiant)).

[DonQuiche]

Bonjour. Pour clarifier un peu ce qui vient d'être dit, non on ne peut pas éviter le lancement de WPFFontCache. Ce service est exécuté la première fois qu'un programme WPF est lancé dans la session et il est nécessaire à toutes les applis WPF. Il me semble que sous Seven/Vista ce services est lancé au démarrage du système.

Quant à FrameworkServices, je ne connaissais pas, ça semble être lié à McAfee, ça vient donc de ton antivirus.

En revanche, GurruMeditation donne de bonnes pistes pour améliorer la vitesse et l'impression de vitesse. Pour préciser :
* Ngen peut réduire la vitesse de lancement de l'appli (appli pré-compilée, donc pas de JIT = moins de boulot CPU mais plus de données à lire depuis le disque).
* Pour le splashscreen il s'agit d'une fenêtre n'utilisant pas WPF et elle est donc affichée avec de commencer le chargement de ce dernier. On trouve plein d'exemples sur le web, ta question étant un souci assez fréquent avec WPF.

[takinelinfo]

Merci à vous deux. Je ne connais absolument pas Ngen. Je vais donc regarder à quoi ça sert et voir comment l'utiliser.

Pour le splashscreen, je l'ai déjà en place.

En fait voilà ce qui me choque.

1) Je lance mon application pour la 1ère fois.
Démarrage => 20s
Je la quitte.

2) Je relance mon application
Démarrage => 6s

Je suppose donc qu'il y a des actions faites au 1er démarrage qui ne sont pas faites au 2ème. En fait je voudrais les identifier pour savoir comment je peux gagner du temps en simulant un démarrage à chaud.

Exemple: Si c'est du à des processus qui se lance, j'aurais par exemple fait juste une fenêtre en hidden dans un .exe qui se lancerait au démarrage. Ainsi lors du lancement de mon application, je gagne en chargement.

[DonQuiche]

Tous les problèmes liés à WPF sont ceux posés par WPFFontCache et, effectivement, une bête fenêtre invisible au démarrage du système éviterait ça. Cela dit, c'est le genre de pratique que nombre d'utilisateurs haïssent puisque cela revient à ralentir le démarrage de leur machine pour donner une impression de vélocité à ton produit. Personnellement j'organise des messes noires tous les vendredis pour apporter malheur et impuissance à tous les codeurs qui ont ainsi tenté de coloniser mon système.

Quant au problème posé par McAfee, en revanche, je ne pense pas que cette solution y changera grand chose.

[GuruuMeditation]

Je suppose donc qu'il y a des actions faites au 1er démarrage qui ne sont pas faites au 2ème. En fait je voudrais les identifier pour savoir comment je peux gagner du temps en simulant un démarrage à chaud.

En démarrage à chaud, il y a toutes sortes de choses qui se trouvent déjà quelque part en mémoire parce qu'elles ont été chargées lors du démarrage à froid. En gros, on ne peut pas y faire grand-chose ( part peut-être lancer une appli WPF plus légère avant, ce qui fait que le démarrage a froid de l'appli 1 + le démarrage semi chaud appli 2 sera peut-être plus rapide que le démarrage à froid de l'appli 2)
Mais c'est du chipotage et pas sur de tout que ça marche, et peut même avoir des résultats différent sur des machines différentes