Je suis attéré de voir que quand je lance un de mes projets en VB.net, un programme d’une 30Ko (du moins il fait une 30Ko en VB6, vu que je suis en train de convertir du code) est capable d’avoir une empreinte mémoire de 30Mo. De mettre 40 secondes a se lancer sur un XP2400 512DDR.
Pourquoi tant de haine?
Je veux dire, mon programme ne fait qu’appel a des APIs windows pour simuler un comportement utilisateur (je clique n’importe ou, je tape n’importe quoi, ouais c’est mon programme stress test pour mes autres programmes) complètement idiot. Alors comment se fait il qu’il ai une empreinte mémoire aussi grosse?
Microsoft a t’il des actions chez les fabriquants de mémoire?
La mémoire est elle gratuite?
Vais je enfin trouver pourquoi Zorglub se fait attaquer par Procyon?
Meme si il prend 30 megs en memoire (ce qui est pas si surprenant que ca) ca devrait pas prendre 40 secondes a se lancer sur un 2400
J’ai fout tout les devel de mes app sur un 2000+ avec 512 megs et si c’est pas giga instantane ca s’en approche severement.
Ensuite ca vient de la maniere dont sont decoupees les dll en .net ET du garbage collector. La « memoire consomee » indiquee est pas revelatrice de la vrai memoire allouee par l’appli, parceque 1) la memoire peut etre en instance d’etre liberee voire etre deja libre mais pas indiquee comme telle 2) la memoire a pu etre pre-allouee par le framework pour gagner en performance.
Ensuite system.dll fait 2 megs, system.windows.forms.dll fait 2 megs, system.data.dll fait 1.2 megs, system.drawing.dll fait 500ko, etc. A cela il faut ajouter la compilateur JIT, la place pour le framework, etc. Ca monte vite. Si ton programme fait 30ko c’est parceque tout le code complique est ailleurs et que tu ne fais que l’appeller. Bien sur elles sont chargees a un seul exemplaire pour le systeme, encore une fois les chiffres indiques sont donc pas forcement revelateurs.
Sinon, oui, le memory footprint est pas une contrainte d’optimisation majeure. Les temps de chargement eux le sont, donc par defaut la taille allouee doit pas etre trop grande mais ce qui nous interesse c’est en priorite le temps de chargement, pas la taille finalle en memoire. La memoire est pas chere et 512 est maintenant un standard, donc si on fait quand meme attetion de pas faire vraiment nawak, on a d’autre priorites qui passent devant l’occupation memoire.
Cela dit la maniere dont sont decoupees les dll est toujours une grosse source de debat entre plein de petites dll qui chargent vitent et qui sont modulaires mais pas pratiques a utiliser et qui ralentissent du fait qu’il y en a plein, ou des plus grosse monolithiques ou si tu veux juste utiliser un petit truc dedans il te faut quand meme charger plein de trucs dont t’as rien a peter… vaste debat, maintes fois debatus dans les couloirs des buildings 41/42 et qui est loin d’etre fini pour longhorn et la suite du schmilblick…
PS EDIT:
si vous voyez des sites ca et la qui recommendent de faire un SetWorkingSet dans Kernel32.dll pour « tricher » ne le faites SURTOUT PAS. C’est tellement mal que ca me donne des boutons, c’est tout peter le travail qui a ete fait dans le CLR pour gerer tout ca en passant par dessous. C’est le truc INTERDIT. Donc ces conseils bidons sont a eviter comme la peste, j’aurais meme pas du citer le nom de la fonction…
[quote name=‘GloP’ date=’ 10 Dec 2004, 11:12’]si vous voyez des sites ca et la qui recommendent de faire un SetWorkingSet dans Kernel32.dll pour “tricher” ne le faites SURTOUT PAS. C’est tellement mal que ca me donne des boutons, c’est tout peter le travail qui a ete fait dans le CLR pour gerer tout ca en passant par dessous. C’est le truc INTERDIT. Donc ces conseils bidons sont a eviter comme la peste, j’aurais meme pas du citer le nom de la fonction…
[right][post=“311688”]<{POST_SNAPBACK}>[/post][/right][/quote]
Je confirmes il met bien 30 a 40 secondes a se lancer: je pense que cela vient du fait que j’ai pas le framework lancé auparavant (le 2400 est la bécanne de test, pas de développement). Il faudrait que je quitte le programme une fois et que je le relance pour voir si c’est plus rapide.
Ps: 30 Mo c’est beaucoup quand on a un système avec 128Mo de mémoire. J’ai pas envie de faire une appli qui tourne que sur les monstres d’aujourdhui mais aussi sur les monstres d’hier et c’est aussi pourquoi j’ai longtemps hésité a utiliser .net. Maintenant si tu me dis qu’on peut encore se passer du framework tout en utilisant la puissance des editeurs de whidbey, je prends :P.
[quote name=‹ ZGoblin › date=’ 10 Dec 2004, 06:04’]Pour info, ca consite en quoi ?
[right][post=« 311771 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Non non j’explique pas. Une recherche google sur la fonction devrait te donner ton bonheur, mais tu l’as pas entendu venant de moi
Sinon… t’as pas le choix, ou t’utilise la puissance du truc et tu fais du .net ou tu fais tout en MFC ou en ATL en C++ et heu… t’as pas grand chose
