Discussion :

[TSalm]

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.

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 ?

D'avance merci pour vos idées ,
TSalm

[_skip]

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.

[SaumonAgile]

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.

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

Mais c'est pourtant toujours le même exe managé qui est lancé.
Pourquoi DOTNET ne maintient t-il pas un cache de ce qu'il a compilé ?

[SaumonAgile]

Pourquoi DOTNET ne maintient t-il pas un cache de ce qu'il a compilé ?

Parce que ça n'a pas de sens
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 ?

[dev01]

Parce que ça n'a pas de sens
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 , la clef utilisé est la signature de l'assembly. D'ailleur as tu fait le test de signer ton app ?

Et surtout ton app fait-elle appelle à des bases de données ? ou autre compo externe ?

[_skip]

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.

[SaumonAgile]

il y a un cache des assemblies compilé, il me semble , la clef utilisé est la signature de l'assembly. D'ailleur as tu fait le test de signer ton app ?

Et surtout ton app fait-elle appelle à des bases de données ? ou autre compo externe ?

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é.

[TSalm]

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.

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