Lorsque l'on lance une application développée en VS2005 sur un poste client,
même un simple écran et un bouton, c'est très long à charger... par contre si
je ferme cette application et je la relance une seconde fois, c'est beaucoup
plus rapide!!!
Mes postes clients sont en Windows XP SP1 et SP2.
Si quelqu'un a déjà vu ou eu ce problème très mystérieux...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian Hugoud
Hi,
Rien de très mystérieux en fait : l'appli lance le framework qui doit se charger. Une fois en mémoire (dans le cache, par exemple), il est plus rapidement accessible pour l'appli.
En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
Christian
"Romuald" a écrit dans le message de news:
Salut,
Lorsque l'on lance une application développée en VS2005 sur un poste client, même un simple écran et un bouton, c'est très long à charger... par contre si je ferme cette application et je la relance une seconde fois, c'est beaucoup plus rapide!!!
Mes postes clients sont en Windows XP SP1 et SP2.
Si quelqu'un a déjà vu ou eu ce problème très mystérieux...
Merci.
Hi,
Rien de très mystérieux en fait : l'appli lance le framework qui doit se
charger. Une fois en mémoire (dans le cache, par exemple), il est plus
rapidement accessible pour l'appli.
En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
Christian
"Romuald" <Romuald@discussions.microsoft.com> a écrit dans le message de
news: 3827CCF7-67D7-4269-99C3-B67B69025353@microsoft.com...
Salut,
Lorsque l'on lance une application développée en VS2005 sur un poste
client,
même un simple écran et un bouton, c'est très long à charger... par contre
si
je ferme cette application et je la relance une seconde fois, c'est
beaucoup
plus rapide!!!
Mes postes clients sont en Windows XP SP1 et SP2.
Si quelqu'un a déjà vu ou eu ce problème très mystérieux...
Rien de très mystérieux en fait : l'appli lance le framework qui doit se charger. Une fois en mémoire (dans le cache, par exemple), il est plus rapidement accessible pour l'appli.
En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
Christian
"Romuald" a écrit dans le message de news:
Salut,
Lorsque l'on lance une application développée en VS2005 sur un poste client, même un simple écran et un bouton, c'est très long à charger... par contre si je ferme cette application et je la relance une seconde fois, c'est beaucoup plus rapide!!!
Mes postes clients sont en Windows XP SP1 et SP2.
Si quelqu'un a déjà vu ou eu ce problème très mystérieux...
Merci.
Mehdi
On Mon, 12 Jun 2006 19:21:06 +0200, Christian Hugoud wrote:
Rien de très mystérieux en fait : l'appli lance le framework qui doit se charger. Une fois en mémoire (dans le cache, par exemple), il est plus rapidement accessible pour l'appli.
En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
En fait, ce n'est pas vraiment ca. Le fait que le CLR ai a démarrer est effectivement un facteur dans le fait que les applis .NET soient assez lentes a se lancer mais pas le facteur principal. Le "probleme" est que les applications .NET sont JIT-compilées (Just In Time - compilées juste a temps).
Lorsque tu compiles une appli .NET dans Visual Studio, le code généré n'est pas du code machine mais du code intermédiaire (MSIL - Microsoft Intermediate Language). Ce code n'est pas executable en l'état. Lorsque l'appli est lancée, le compilateur JIT se lance et compile le code IL en code machine puis l'application s'execute. C'est cette phase de compilation JIT qui ralentit le lancement de l'application. Une fois l'application JIT-compilée, le code machine résultant est stocké sur la machine et réutilisé lorsque l'appli est relancée, évitant ainsi d'avoir a la JIT-compiler a chaque fois qu'elle se lance. C'est pourquoi seul le premier lancement de l'application est vraiment lent. L'avantage de la compilation JIT est que le compilateur JIT, compilant directement sur la machine sur laquelle l'appli va s'executer, connait la confiuration matérielle et logicielle exacte de cette machine et peut donc optimiser le code machine généré pour cette configuration particuliere. Une fois lancée, l'application est donc (en théorie) optimisée pour ton systeme et ton processeur particulier et peut pleinement tirer parti de ta config.
Le probleme est que lorsque l'application devient assez grosse, cette phase de compilation JIT peut prendre beaucoup de temps et laisser penser a l'utilisateur que l'appli a planté (ou en tout cas lui donner une tres mauvaise impression des le départ). Il est en fait possible d'intégrer la compilation JIT a ton installeur a l'aide tu programme NGen, ce qui permet d'avoir le code machine généré lors de l'installation du logiciel au lieu d'attendre son premier lancement. Voir cet article pour plus de détails: <http://bobpowell.net/prejit.htm>
On Mon, 12 Jun 2006 19:21:06 +0200, Christian Hugoud wrote:
Rien de très mystérieux en fait : l'appli lance le framework qui doit se
charger. Une fois en mémoire (dans le cache, par exemple), il est plus
rapidement accessible pour l'appli.
En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
En fait, ce n'est pas vraiment ca. Le fait que le CLR ai a démarrer est
effectivement un facteur dans le fait que les applis .NET soient assez
lentes a se lancer mais pas le facteur principal. Le "probleme" est que les
applications .NET sont JIT-compilées (Just In Time - compilées juste a
temps).
Lorsque tu compiles une appli .NET dans Visual Studio, le code généré n'est
pas du code machine mais du code intermédiaire (MSIL - Microsoft
Intermediate Language). Ce code n'est pas executable en l'état. Lorsque
l'appli est lancée, le compilateur JIT se lance et compile le code IL en
code machine puis l'application s'execute. C'est cette phase de compilation
JIT qui ralentit le lancement de l'application. Une fois l'application
JIT-compilée, le code machine résultant est stocké sur la machine et
réutilisé lorsque l'appli est relancée, évitant ainsi d'avoir a la
JIT-compiler a chaque fois qu'elle se lance. C'est pourquoi seul le premier
lancement de l'application est vraiment lent. L'avantage de la compilation
JIT est que le compilateur JIT, compilant directement sur la machine sur
laquelle l'appli va s'executer, connait la confiuration matérielle et
logicielle exacte de cette machine et peut donc optimiser le code machine
généré pour cette configuration particuliere. Une fois lancée,
l'application est donc (en théorie) optimisée pour ton systeme et ton
processeur particulier et peut pleinement tirer parti de ta config.
Le probleme est que lorsque l'application devient assez grosse, cette phase
de compilation JIT peut prendre beaucoup de temps et laisser penser a
l'utilisateur que l'appli a planté (ou en tout cas lui donner une tres
mauvaise impression des le départ). Il est en fait possible d'intégrer la
compilation JIT a ton installeur a l'aide tu programme NGen, ce qui permet
d'avoir le code machine généré lors de l'installation du logiciel au lieu
d'attendre son premier lancement. Voir cet article pour plus de détails:
<http://bobpowell.net/prejit.htm>
On Mon, 12 Jun 2006 19:21:06 +0200, Christian Hugoud wrote:
Rien de très mystérieux en fait : l'appli lance le framework qui doit se charger. Une fois en mémoire (dans le cache, par exemple), il est plus rapidement accessible pour l'appli.
En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
En fait, ce n'est pas vraiment ca. Le fait que le CLR ai a démarrer est effectivement un facteur dans le fait que les applis .NET soient assez lentes a se lancer mais pas le facteur principal. Le "probleme" est que les applications .NET sont JIT-compilées (Just In Time - compilées juste a temps).
Lorsque tu compiles une appli .NET dans Visual Studio, le code généré n'est pas du code machine mais du code intermédiaire (MSIL - Microsoft Intermediate Language). Ce code n'est pas executable en l'état. Lorsque l'appli est lancée, le compilateur JIT se lance et compile le code IL en code machine puis l'application s'execute. C'est cette phase de compilation JIT qui ralentit le lancement de l'application. Une fois l'application JIT-compilée, le code machine résultant est stocké sur la machine et réutilisé lorsque l'appli est relancée, évitant ainsi d'avoir a la JIT-compiler a chaque fois qu'elle se lance. C'est pourquoi seul le premier lancement de l'application est vraiment lent. L'avantage de la compilation JIT est que le compilateur JIT, compilant directement sur la machine sur laquelle l'appli va s'executer, connait la confiuration matérielle et logicielle exacte de cette machine et peut donc optimiser le code machine généré pour cette configuration particuliere. Une fois lancée, l'application est donc (en théorie) optimisée pour ton systeme et ton processeur particulier et peut pleinement tirer parti de ta config.
Le probleme est que lorsque l'application devient assez grosse, cette phase de compilation JIT peut prendre beaucoup de temps et laisser penser a l'utilisateur que l'appli a planté (ou en tout cas lui donner une tres mauvaise impression des le départ). Il est en fait possible d'intégrer la compilation JIT a ton installeur a l'aide tu programme NGen, ce qui permet d'avoir le code machine généré lors de l'installation du logiciel au lieu d'attendre son premier lancement. Voir cet article pour plus de détails: <http://bobpowell.net/prejit.htm>
Romuald
Salut Mehdi,
Merci pour toutes ces infos détaillées, et très claires...
En résumé, si je veux que mon application démarre plus vite au premier lancement, je dois utiliser l'outil "ngen.exe" au moment de l'installation par exemple pour créer une image native de mon application.
Comment je peux utiliser cet outil ? Voici ce que j'ai fait :
1 - Sous "cmd", j'ai pointer sur le fichier "ngen.exe" pour le Framework 2. 2 - J'ai saisi : "ngen.exe c:program filesmy applicationapp.exe" 3 - Il a compilé correctement apparemment, pas de message d'erreur. 4 - J'ai lancé mon appli, mais toujours la même vitesse la première fois, et beaucoup plus rapide la seconde...
Est ce que j'aurais oublié quelque chose dans ma manipulation ?
"Mehdi" a écrit :
On Mon, 12 Jun 2006 19:21:06 +0200, Christian Hugoud wrote:
> Rien de très mystérieux en fait : l'appli lance le framework qui doit se > charger. Une fois en mémoire (dans le cache, par exemple), il est plus > rapidement accessible pour l'appli. > > En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
En fait, ce n'est pas vraiment ca. Le fait que le CLR ai a démarrer est effectivement un facteur dans le fait que les applis .NET soient assez lentes a se lancer mais pas le facteur principal. Le "probleme" est que les applications .NET sont JIT-compilées (Just In Time - compilées juste a temps).
Lorsque tu compiles une appli .NET dans Visual Studio, le code généré n'est pas du code machine mais du code intermédiaire (MSIL - Microsoft Intermediate Language). Ce code n'est pas executable en l'état. Lorsque l'appli est lancée, le compilateur JIT se lance et compile le code IL en code machine puis l'application s'execute. C'est cette phase de compilation JIT qui ralentit le lancement de l'application. Une fois l'application JIT-compilée, le code machine résultant est stocké sur la machine et réutilisé lorsque l'appli est relancée, évitant ainsi d'avoir a la JIT-compiler a chaque fois qu'elle se lance. C'est pourquoi seul le premier lancement de l'application est vraiment lent. L'avantage de la compilation JIT est que le compilateur JIT, compilant directement sur la machine sur laquelle l'appli va s'executer, connait la confiuration matérielle et logicielle exacte de cette machine et peut donc optimiser le code machine généré pour cette configuration particuliere. Une fois lancée, l'application est donc (en théorie) optimisée pour ton systeme et ton processeur particulier et peut pleinement tirer parti de ta config.
Le probleme est que lorsque l'application devient assez grosse, cette phase de compilation JIT peut prendre beaucoup de temps et laisser penser a l'utilisateur que l'appli a planté (ou en tout cas lui donner une tres mauvaise impression des le départ). Il est en fait possible d'intégrer la compilation JIT a ton installeur a l'aide tu programme NGen, ce qui permet d'avoir le code machine généré lors de l'installation du logiciel au lieu d'attendre son premier lancement. Voir cet article pour plus de détails: <http://bobpowell.net/prejit.htm>
Salut Mehdi,
Merci pour toutes ces infos détaillées, et très claires...
En résumé, si je veux que mon application démarre plus vite au premier
lancement, je dois utiliser l'outil "ngen.exe" au moment de l'installation
par exemple pour créer une image native de mon application.
Comment je peux utiliser cet outil ? Voici ce que j'ai fait :
1 - Sous "cmd", j'ai pointer sur le fichier "ngen.exe" pour le Framework 2.
2 - J'ai saisi : "ngen.exe c:program filesmy applicationapp.exe"
3 - Il a compilé correctement apparemment, pas de message d'erreur.
4 - J'ai lancé mon appli, mais toujours la même vitesse la première fois, et
beaucoup plus rapide la seconde...
Est ce que j'aurais oublié quelque chose dans ma manipulation ?
"Mehdi" a écrit :
On Mon, 12 Jun 2006 19:21:06 +0200, Christian Hugoud wrote:
> Rien de très mystérieux en fait : l'appli lance le framework qui doit se
> charger. Une fois en mémoire (dans le cache, par exemple), il est plus
> rapidement accessible pour l'appli.
>
> En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
En fait, ce n'est pas vraiment ca. Le fait que le CLR ai a démarrer est
effectivement un facteur dans le fait que les applis .NET soient assez
lentes a se lancer mais pas le facteur principal. Le "probleme" est que les
applications .NET sont JIT-compilées (Just In Time - compilées juste a
temps).
Lorsque tu compiles une appli .NET dans Visual Studio, le code généré n'est
pas du code machine mais du code intermédiaire (MSIL - Microsoft
Intermediate Language). Ce code n'est pas executable en l'état. Lorsque
l'appli est lancée, le compilateur JIT se lance et compile le code IL en
code machine puis l'application s'execute. C'est cette phase de compilation
JIT qui ralentit le lancement de l'application. Une fois l'application
JIT-compilée, le code machine résultant est stocké sur la machine et
réutilisé lorsque l'appli est relancée, évitant ainsi d'avoir a la
JIT-compiler a chaque fois qu'elle se lance. C'est pourquoi seul le premier
lancement de l'application est vraiment lent. L'avantage de la compilation
JIT est que le compilateur JIT, compilant directement sur la machine sur
laquelle l'appli va s'executer, connait la confiuration matérielle et
logicielle exacte de cette machine et peut donc optimiser le code machine
généré pour cette configuration particuliere. Une fois lancée,
l'application est donc (en théorie) optimisée pour ton systeme et ton
processeur particulier et peut pleinement tirer parti de ta config.
Le probleme est que lorsque l'application devient assez grosse, cette phase
de compilation JIT peut prendre beaucoup de temps et laisser penser a
l'utilisateur que l'appli a planté (ou en tout cas lui donner une tres
mauvaise impression des le départ). Il est en fait possible d'intégrer la
compilation JIT a ton installeur a l'aide tu programme NGen, ce qui permet
d'avoir le code machine généré lors de l'installation du logiciel au lieu
d'attendre son premier lancement. Voir cet article pour plus de détails:
<http://bobpowell.net/prejit.htm>
Merci pour toutes ces infos détaillées, et très claires...
En résumé, si je veux que mon application démarre plus vite au premier lancement, je dois utiliser l'outil "ngen.exe" au moment de l'installation par exemple pour créer une image native de mon application.
Comment je peux utiliser cet outil ? Voici ce que j'ai fait :
1 - Sous "cmd", j'ai pointer sur le fichier "ngen.exe" pour le Framework 2. 2 - J'ai saisi : "ngen.exe c:program filesmy applicationapp.exe" 3 - Il a compilé correctement apparemment, pas de message d'erreur. 4 - J'ai lancé mon appli, mais toujours la même vitesse la première fois, et beaucoup plus rapide la seconde...
Est ce que j'aurais oublié quelque chose dans ma manipulation ?
"Mehdi" a écrit :
On Mon, 12 Jun 2006 19:21:06 +0200, Christian Hugoud wrote:
> Rien de très mystérieux en fait : l'appli lance le framework qui doit se > charger. Une fois en mémoire (dans le cache, par exemple), il est plus > rapidement accessible pour l'appli. > > En fait, ce n'est pas l'appli qui est longue à charger, c'est le framework.
En fait, ce n'est pas vraiment ca. Le fait que le CLR ai a démarrer est effectivement un facteur dans le fait que les applis .NET soient assez lentes a se lancer mais pas le facteur principal. Le "probleme" est que les applications .NET sont JIT-compilées (Just In Time - compilées juste a temps).
Lorsque tu compiles une appli .NET dans Visual Studio, le code généré n'est pas du code machine mais du code intermédiaire (MSIL - Microsoft Intermediate Language). Ce code n'est pas executable en l'état. Lorsque l'appli est lancée, le compilateur JIT se lance et compile le code IL en code machine puis l'application s'execute. C'est cette phase de compilation JIT qui ralentit le lancement de l'application. Une fois l'application JIT-compilée, le code machine résultant est stocké sur la machine et réutilisé lorsque l'appli est relancée, évitant ainsi d'avoir a la JIT-compiler a chaque fois qu'elle se lance. C'est pourquoi seul le premier lancement de l'application est vraiment lent. L'avantage de la compilation JIT est que le compilateur JIT, compilant directement sur la machine sur laquelle l'appli va s'executer, connait la confiuration matérielle et logicielle exacte de cette machine et peut donc optimiser le code machine généré pour cette configuration particuliere. Une fois lancée, l'application est donc (en théorie) optimisée pour ton systeme et ton processeur particulier et peut pleinement tirer parti de ta config.
Le probleme est que lorsque l'application devient assez grosse, cette phase de compilation JIT peut prendre beaucoup de temps et laisser penser a l'utilisateur que l'appli a planté (ou en tout cas lui donner une tres mauvaise impression des le départ). Il est en fait possible d'intégrer la compilation JIT a ton installeur a l'aide tu programme NGen, ce qui permet d'avoir le code machine généré lors de l'installation du logiciel au lieu d'attendre son premier lancement. Voir cet article pour plus de détails: <http://bobpowell.net/prejit.htm>
