Version imprimable
Bonjour,
J'ai une application non managé qui fait appel à des .exe .NET .
J'ai une l'atrange suprise de constater que ces executables .NET se lancent largement plus vite quand je laisse VS2005 tourner. 8O
Comprends pas bien ...
Comment VS2005 fait t-il pour que mon pgm qui n'a rien à voir avec lui lance mes applis .NET 2X plus vite ? :bug:
D'avance merci pour vos idées ,
TSalm
La raison principale des lenteurs aux démarrages des applications en .net sont la compilation JIT des différentes assemblies.
Lorsque tu as vs2005 qui tourne, certaines de ces assemblies sont déjà en mémoire, ce qui évite à l'environnement d'avoir à complètement les recharger.
Si tu veux accélérer tes applications, tu peux pré-générer une image native à l'aide de ngen, mais cela a aussi des inconvénients non négligeables.
A mon avis, c'est simplement dû au fait que VS fait beaucoup appel aux assemblies .NET, elles sont donc déjà chargées en mémoire quand tu lances ton programme, tu gagnes donc en rapidité vu qu'il ne reste plus que ton propre assembly à charger.
Mais c'est pourtant toujours le même exe managé qui est lancé.Citation:
Envoyé par _skip
Pourquoi DOTNET ne maintient t-il pas un cache de ce qu'il a compilé ?
J'ai fait un test en lançant en arriére plan un assemblie qui utilise les mêmes assemblies, et effectivement, c'est plus performant, mais.... pas autant que si je fait tourner VS2005 :aie:Citation:
Envoyé par SaumonAgile
Parce que ça n'a pas de sens ;)Citation:
Envoyé par TSalm
Qu'est ce que veut mettre en cache ? Une assembly ? Une méthode ? Une classe ?
Comment veux tu différencier un élément du cache d'un autre ?
il y a un cache des assemblies compilé, il me semble :koi:, la clef utilisé est la signature de l'assembly. D'ailleur as tu fait le test de signer ton app ?Citation:
Envoyé par SaumonAgile
Et surtout ton app fait-elle appelle à des bases de données ? ou autre compo externe ?
Le global assembly cache oui.
La seule véritable manière d'améliorer la vitesse DE PREMIERE EXECUTION d'une form ou d'un algo c'est d'utiliser ngen. Avec prudence.
Le GAC ne répond pas à la problématique de garder en cache le code déjà compilé, mais de centraliser les assemblies. C'est bien une assembli en IL qui stocké dans le GAC et non pas le code natif de l'assemblyCitation:
Envoyé par _skip
Sisi, les images natives atterrissent dans une zone réservée du GAC. Mais ce n'est pas la fonction principale du gac, c'était peut etre ambigu dans mon post.
Salut,
quand tu lances ton appli depuis Visual (hypothese : tu le lances en debugage actif (F5)), tu ne lances pas reellement ton programme directement, mais tu passes par un host de process ([Monprogramme].vshost.exe) qui reste actif entre les differents lancement du programme. De fait, tu n'as pas à loader l'ensemble des references de ton programme à chaque lancement, celles ci sont gardées en l'etat entre chaque execution.
Apres ce peut etre aussi d'autres problemes, tu trouveras les solutions courantes dans cet article de MSDN mag.
Bon courage.
ok alors je suis d'accord ;)Citation:
Envoyé par _skip
Oui mais là on parle de précompilation. Je répondais dans le cadre d'une problématique de garder en cache ce qui est jitté.Citation:
Envoyé par dev01
Merci pour le lien SirJulio, il est super :king:Citation:
Envoyé par SirJulio