voila je fais une appli assez importante (mais tant que ca !)
qui me prends 9 Mo de memoire
 
on m a dit que c etait a cause du fait que je chargerait tout les formulaires au demarrage. Soit donc j ai enleve tt les chargement.
 
Au demarrage il y a juste un petit icone en bas a droite a cote de l heure et ca prends toujours presque 9 Mo.
 
Qu est ce qui peutt causer ca ?
 
en mode debug j ai fais tourner le logiciel et apres les initialisations le prog ne fais rien
 
9 Mo pr rien faire a part afficher un icone ca me parait bcp
 
j utilise VB6 avec des modules classes

Ben il charge quand même tout l'EXE en mémoire, c'est valable non seulement pour VB6 mais pour n'importe quel langage.  Et dès tu crées des objets, forcément, ça bouffera un peu plus.  Tu peux t'estimer heureux de ne bouffer que 9MB d'ailleurs
 
pour exemple, j'ai un exe de 5.6MB sur mon disque dur (fait en VB également).  Une fois l'écran principal chargé, ça en bouffe déjà 12MB
 
Dans l'occupation mémoire, tu devras aussi compter les DLL, runtimes, OCX et compagnie auxquels ton programme fait appel.

euh le probleme c est que mon exe ne depasse pas les 150 ko
 
sinon les dll etc ... sont entierment chargé en memoire ?
 

ah ben a priori oui
 
il accède à quoi ton EXE?  databases?  contrôles non-standards?  références?

Faut aussi faire gaffe aux variable que tu déclares dans les "dim".
 
Si tu crées array de string*255 de 1 million de lignes, ben ça bouffera 255 Mo de RAM avant même que tu écrives dedans...
 
Sinon, aussi, conseil : ne dimensionne pas tes objets.
 
Au lieu par exemple d'écrire :
 
dim cnx as ADODB.Connection ' Mémoire occupée : la taille de l'objet, soit plusieurs centaines Ko.
 
et plus loin dans ton code :
 
set cnx = new ADODB.Connection ' Ecriture de l'objet dans la zone réservée
 
A la place, utilise :
 
dim cnx as object ' Mémoire occupée : 1 pointeur, soit 32 bits
 
et plus loin dans ton code :
 
set cnx = createobject("ADOB.Connection" ) ' Création d'un espace réservé pour l'objet, et instanciation
 
=> L'objet ne sera chargé qu'au moment où tu vas l'instancier. Ce sera beaucoup plus lent, mais ça économisera énormément de mémoire.

que ce soit early ou late binding, c'est et ça reste un pointeur, donc 32 bits dans tous les cas
 
Tu vas pas me dire que VB réserve "à l'avance" l'espace mémoire nécessaire pour un objet en early binding?  Pour un Dim Machin as New ClassTruc je veux bien mais quand le New n'est pas spécifié?

en fait j utilise deux classes qui en sont pas de taille tres consequentes
 
j utilise des tableaux mais y a jamais plus de 10 elements dedans
 
mon appli fait des shellexecute
fait des acces sur un serveur web
 
y a quelques timers
quelques winsocks
 
c est tout

bon en fait t'as dit une boulette sur les objets, j'ai vérifié
 
tant que t'as pas utilisé l'opérateur New ou l'instruction CreateObject, ya rien en mémoire.

ha bon ? je croyais

ben oui, c'est juste des pointeurs.
 
Si ça se passait comme tu disais, l'instruction "set MonObjet = MonAutreObjet" crérait une copie de MonAutreObjet dans monObjet et les modifs ultérieures effectuées sur MonAutreObjet n'affecteraient pas MonObjet, or ce n'est pas le cas (tested and aprouved).

je viens de voir qu il y a des options dans la creationd e l exe
 
est ec que ca peut venir de la ?

Les options par défaut ne doivent pas poser de problème, même à ce niveau.  Eventuellement, coche Favor Pentium Pro pour ajouter une optimisation supplémentaire.
 
De plus, le compilateur vire par défaut toute référence non-utilisée (chuis obligé de décocher ça parce que j'utilise des contrôles custom alloués dynamiquement).

T sûr que les processeurs PMMX/Pii/Piii/Piv/Athlon ont les instructions P Pro ? J'ai jamais testé, mais j'ai jamais compilé pour P Pro, de peur d'empirer les choses

Je ne suis pas sûr de ce point mais je dirais que le code est optimisé (ça fait bizarre de dire ça quand on parle de VB ) pour l'architecture PPro.  Chuis pas sûr que VB exploite le microcode spécifique à ce processeur.  D'ailleurs il dit bien "Favor PPro", et le libellé de l'option m'incite à voir la chose comme ça.
 
Voici ce qu'en dit l'aide:

 
Donc il s'agit bien d'organiser le code plutôt que d'exploiter un microcode spécifique au PPro.  Donc sûrement que ça n'aura que peu ou pas d'impact sur les processeurs qui ont suivi au niveau perfs.

les P2 et PIII ont la même architecture que le PPro et les optimisations pour PPro profitent aussi au P4 et aux athlon.

c pour ça que j'évite de cocher ça, de peur de réduire encore plus les perfs

OK, bon ben je cocherai cette case dans le future

euh P2 et P3 OK.  Mais P4, pas du tout d'accord.  C'est une architecture entièrement nouvelle, from scratch comme on dit.  J'ai beaucoup lu à ce sujet et ce processeur a remis en cause des choses qui existaient déjà au temps du 8088 (je ne dis pas que ces choses constituaient un frein ou des problèmes de compatibilité avec la nouvelle architecture).
 
Donc ils n'ont pas forcément eu raison.  Il y avait tellement de transistors dans leur design qu'ils ont été obligés de couper pas mal de choses, ce qui a donné le premier P4 sorti sur le marché.  Il s'est bien rattrapé depuis niveau perfs mais l'architecture reste tout de même différente du PPro.
 
Quant à l'Athlon, c'est également une autre architecture, développée de plus par un autre fondeur, je ne crois pas que l'option "Favor PPro" va faire évoluer le résultat significativement.
 
Cette optimisation ne concerne vraiment que les PPro, P2 et P3.

les architectures des PPro/P2/PIII, des P4 et des athlon sont effectivement très différentes mais je persiste à dire que les optimisations faitent pour le PPro ont aussi des impacts bénéfiques pour les P4 et athlon. Je me base sur des tests fait par moi et sur cet article (même si c'est pas tout à fait le cas dont on parle):
http://www.onversity.com/cgi-bin/d [...] &P=020&T=0

T'as fait des tests sur différents CPU en VB6?  ça m'intéresse
 
J'aime bien le dernier paragraphe qui ne fait que répéter ce qu'on lit souvent dans ce sujet précis: les compilateurs suivent les processeurs avec 5 ans de retard!  Je parle pas du compilo Intel évidemment puisque lui a sacrément intérêt à être à jour, mais plutôt des habituels produits VC, BC, GCC etc qui eux, ne sont liés à aucun fondeur.
 
En ce qui concerne le P4, son architecture diffère tellement que tout doit être revu pour lui.  Je parle pas pour les SSE et compagnie mais vraiment le core du processeur x86.

Pour les test, j'ai juste mesuré le temps d'execution avec la case cochée ou décochée, sans plus

Il me semblait que le plus grand pas avait été fait lors du passage à l'architecture P6: on est passé d'une architecture CISC à une architecture mixte RISC/CISC.
 
T'as des liens avec plus d'infos ?

un grand pas avait été fait, effectivement, mais le PPro restait largement appuyé sur l'architecture P5 du Pentium.  Le Pentium 4 est comme l'Athlon: une rupture totale avec le passé, exception faite du microcode.
 
J'avais un lien sur le P4 avec force détails et démonstrations en ASM faite par un type qui programme des émulateurs, j'ai sauvé la page quelque part en local mais ce serait bien que je la retrouve sur le web

ayé j'ai retrouvé la page:
 
http://www.emulators.com/docs/pentium_1.htm
 
ça continue sur 4 pages, ya eu des updates depuis, va falloir que je lise tout ça.  C'est évidemment très technique et des notions d'assembleur sont requises à certains endroits.

thx, je regarde ça