rapidité au lancement

Question

Bonjour à Tous,

Comment pré-charger les modules (system, net, etc) en mémoire au préalable pour avoir une efficacité maximum dés le lancement de l'application.
J'ai eu l'information il y a très longtemps lors d'un cours, mais comme je ne me sers du C# qu'aujourd'hui, je n'arrive pas à retrouver l'astuce. Il s'agissait d'une commande en ligne qui permettait de lister les module du framework en mémoire ou d'en charger au préalable.

Merci

pedefe

BruNews · Answer

Sérieusement, faire un truc en .net ou tout autre interprété et attendre une "efficacité maximum", c'est une illusion qu'il convient d'évacuer. Il n'y en aura pas plus au lancement qu'à l'exécution.

ciao...
BruNews, MVP VC++

cs_DARKSIDIOUS · Answer

Salut,

BruNews >> sans commentaires 
______________________________________
DarK Sidious

cs_rt15 · Answer

Salut,

Oublie ces gros trolls et regarde ici. Ils proposent l'inverse : ne pas charger certains modules au démarrage pour aller plus vite.
On t'a peut être parler de vadump.

BruNews · Answer

vi vi, faut de suite aller voir ce qu'ils proposent mais surtout n'emploient jamais.

ciao...
BruNews, MVP VC++

f0xi · Answer

Mauvaise rubrique (Bar alors que CSharp (dot net)) 





<hr size="2" width="100%" />


http://deefaze.gnomz.com

Lutinore · Answer

Salut, tu peux également éliminer la compilation JIT et compiler ton application en code natif avec NGen.exe ( dispo avec le framework ).

BruNews · Answer

en PSEUDO natif, mais toujours bouillie de chat interprétée.

ciao...
BruNews, MVP VC++

Lutinore · Answer

Tu deviens prévisible BruNews..

Bien sûr ça restera une application managée qui tourne sous l'exécution du CLR, dans ce sens là c'est pas l'équivalent d'un exécutable C/C++ mais avec ngen.exe l'application sera déja compilée en code machine ce qui est un gain important par rapport au JIT.

BruNews · Answer

OK tu en compiles un ainsi et tu me l'envoies que je l'analyse, j'y croirai ensuite.

ciao...
BruNews, MVP VC++

cs_coq · Answer

dir %windir%\assembly\NativeImages_v2.0.50727_32\*.ni.dll /s
fait ton choix

/*
coq
MVP Visual C#
CoqBlog
*/

BruNews · Answer

Je n'ai pas ce dossier sur Win Server 2008.

ciao...
BruNews, MVP VC++

cs_coq · Answer

Pas d'édition 64 sous la main mais je suppose que ce sera NativeImages_v2.0.50727_64 au lieu de NativeImages_v2.0.50727_32.
Si le framework .NET est installé, naturellement.

/*
coq
MVP Visual C#
CoqBlog
*/

BruNews · Answer

Posé par force avec VS 2008 mais windir\assembly et 1 seul sous dossier "download", rien de plus.

Allez un petit coup de zip svp, j'aimerais vraiment jeter un oeil sur ces binaires "compilés".

ciao...
BruNews, MVP VC++

cs_coq · Answer

Ne regarde pas par l'explorer, il y a une extension du shell qui personnalise un poil l'affichage.
D'où la cmd, ou au pire passe par Winrar, il te laissera voir les chose sous leur forme réelle.

/*
coq
MVP Visual C#
CoqBlog
*/

Lutinore · Answer

Avec le framework tu as forcement ce dossier Assembly qui contient les images natives compilées spécifiquement pour ta machine.

Envoyé par mail pour l'analyse mais n'espère pas l'exécuter tel quel, il faudrait générer et installer le ficher sur ta machine pour ça.

BruNews · Answer

Merci pour l'envoi.

Sur sytem 64 comme sur 32, on obtient l'injurebox comme quoi ce n'est pas une appli Win32 valide, mystique ça. Si compilé natif, on devrait avoir point d'entrée non trouvé dans dll xxx ou message de ce genre mais image binaire valide.

On voit d'autres trucs marrants dedans:
....
mov esi, eax
mov edi, esi
mov eax, esi
pop edi
pop esi
ret 0

Tout ceci ne fait absolument rien, les 3 MOV avant les POPs ne servent strictement à que dalle. Les POPs avant le RET indique bien une sortie de fonction correcte mais cet entassement d'instructions inutiles reste un mystère.
Je peux continuer à coder tranquille, c'est pas demain qu'on produira un logiciel avec pareille bouillie.

ciao...
BruNews, MVP VC++

Lutinore · Answer

Et encore t'as pas vu une application WPF avec son code XAML pré-compilé en BAML et contenu comme ressource dans l'exécutable.

cs_coq · Answer

Il n'a jamais été question d'executable autonome.

/*
coq
MVP Visual C#
CoqBlog
*/

BruNews · Answer

Ce n'est carrément pas exécutable du tout, c'est une injurebox "IMAGE BINAIRE INVALIDE" qu'on obtient au lieu que le loader system afficherait la 1ere dépendance non trouvée.
C'est la CLR qui en fera du code exécutable après COMPLETE INTERPRETATION, rien à voir avec du compilé natif comme dit qlqs post plus tôt.

ciao...
BruNews, MVP VC++

cs_coq · Answer

Oui, ngen n'a jamais permit de se passer de la CLR, ni de l'assembly de départ d'ailleurs.
http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

/*
coq
MVP Visual C#
CoqBlog
*/

Rapidité au lancement

24 réponses

Votre réponse

Discussions similaires