Utilisateur anonyme
-
27 avril 2006 à 22:37
elguevel
Messages postés718Date d'inscriptionjeudi 19 décembre 2002StatutMembreDernière intervention22 novembre 2016
-
29 avril 2006 à 10:11
Salut,
En ce moment je suis entré de réaliser une application console. Et en fait l'executable fait 500k. Je trouve que cela fait bcp pour un mode console surtout que le code est court. Quant pensez vous ?
Ah oui je vous passe les uses :
Windows, Messages, SysUtils, Classes, Forms, IdMessage, IdBaseComponent,
IdComponent, IdMessageClient, IdSMTP, registry, IdSocks, wininet, Winsock, ShellAPI;
f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 202235 27 avril 2006 à 22:57
ah ben forcement, si tu inclus des objets non visuel dans ton application, forcement cela augmente beaucoup la taille.
meme si le code dans l'unité n'est pas enorme.
mais si tu regarde bien, la plupart des executable de moins de 100Ko sont generalement associé a une ou plusieur DLL qui elle vont faire plus de 100Ko .. (exemple)
donc au final, l'appli pese toujours aussi lourd, sauf que l'executable lui ... pese plus ou moins lourd.
contrairement a VB ou appli .NET qui necessite l'installation de librairie ou d'un framework qui pese hyper lourd et surtout qui sont super lourd ...
si la taille de ton appli te gene, regarde vite fait l'utilitaire UPX (c'est un petit executable) qui permet de compresser les appli avec un rapport de compression vraiment interressant.
une appli normal qui pese generalement entre 500 et 800Ko se retrouve facilement sous la barre des 300 - 250Ko
ce qui n'est pas negligeable.
florenth
Messages postés1023Date d'inscriptiondimanche 1 août 2004StatutMembreDernière intervention17 août 20083 28 avril 2006 à 11:11
@ Francky : si tu voulais faire une appli console pour gagner de la place et/o de la rapidité, je crois que tu peux laisser tomber. En plus, toutesles procédures d'affichages, de menus, etc... sont pus plus soulants à coder en mode console qu'en application avec des fiches.
@ f0xi: il me semblait que ce n'étais pas très bien de compresser un executable mais je ne me souviens plus pourquoi (raison de performances ??). Si je retrouve ça, je te le dis
++
Si tu ne te plantes pas ......
tu ne pousseras jamais
cs_shining
Messages postés304Date d'inscriptionlundi 30 décembre 2002StatutMembreDernière intervention10 mars 2012 28 avril 2006 à 16:47
un fichier non compressé ne prend pas forcement moins de place en mémoire !!!
on va dire qu'on a une Application lourde avec 55 fiches(Big Project !!!), d'après vous ?? est-ce que nos fiches prennent moins de place en mémoire ??
rappelez vous d'une chose importante !!! à chaque fois que vous ajouter une fiche, Delphi ajoute à l'Entry-Point ceci:
Application.CreateForm(TFrmMain, FrmMain); <=== donc vous aurez 54 fiches qui seront créer puis cachées !!! on ne compte pas la fiche main !!, c'est pour cette raison qu'il vaut mieux retirer cette déclaration et ne faire appel à CreateForm que si vous en avez besoin dans l'imédiat !!! sinon c'est du gaspillage de mémoire pour rien !!!
mais bon ce n'est pas le sujet je sais !!!, d'ailleurs.. loin de moi l'idée d'en faire une Paul & Mickey la dessus !!! lol
en ce qui concerne le sujet
SysUtils <== 30ko sous D6 gourmand en place pas autant que Forms mais si c'est juste pour faire StrToInt ça fait cher payé !!!
Classes <=== 137ko sous D6 mais difficile de s'en passer !!! sauf si ton Appli n'est pas orienté "Poux"
Forms <=== 374ko sous D6 no comment lol
IdBaseComponent <== bon les composants Indy son généralement volumineux car une unité fait appel à une autre ect...
registry <=== 137Ko sous D6, elle aussi prend de la place, il existe sur le net une registrylite qui ne fait que 7 ko
pour les débutants :
pour savoir le poids d'une unité avec votre version Delphi c'est simple, il suffit de créer une Application console, de retirer la clause USES
Sans rien Delphi nous pond un petit 8Ko dû à l'unité System.pas ect.., ensuite mettre par exemple registry dans la clause uses et soustraire le poids avec le poids sans rien '8ko' précédent on voit vite quelles sont les unités plus ou moins gourmandes en poids !!!
Vous n’avez pas trouvé la réponse que vous recherchez ?
Emandhal
Messages postés194Date d'inscriptiondimanche 2 mars 2003StatutMembreDernière intervention10 octobre 20063 28 avril 2006 à 18:18
Perso si c'est juste pour un StrToInt, je copie la fonction dans mon projet et je vire la clause dans les uses ^^
Dans son cas, fais comme cirec et je met les clauses une par une en commentaire et je regarde si ca vaut le coup de déplacer les procedure, fonctions, constantes... dans une autre unit de mon projet. C'est barbare mais ca marche plutot bien. Par contre je le fais que lorsque j'ai fini mon projet. Il y a bien un dérivé de cette méthode mais là, un niveau expert est nécéssaire...
Pour ce qui est de compresser l'application, il faut penser que l'application décompressée se retrouvera en mémoire.
donc mis a part le surplus de 160Ko en ram ... y'a pas vraiment d'incidence sur le reste.
je veux bien que les premieres version d'UPX etaient un peu "legere" en matiere technique, mais les dernieres sont assée bien et je n'ai jamais relevé de probleme de performance ou d'utilisation avec UPX.
et je pense que quand on depasse 1 ou 2 Mo en ram on se fout completement d'avoir 160Ko en plus.
vus que peu de personne utilise windows XP avec 64Mo de RAM.
mais bon il est vrai que je conseillerais son utilisation a des outils simple qu'on veu pouvoir difuser rapidement sur le net sans qu'ils ne prennent trop de places.
sinon, oui, faire le menage dans les uses,
importer en dur les fonctions des unités comme le dit shining, ce serait idiot de declarer une unité de 70Ko pour une fonction qui fait 3 ou 4 ligne de code ...
elguevel
Messages postés718Date d'inscriptionjeudi 19 décembre 2002StatutMembreDernière intervention22 novembre 20163 29 avril 2006 à 10:11
Sinon tu peux faire une application Graphique en n'utilisant non pas la façon Delphi avec les librairies (uses) courantes, mais à la facon C uniquement avec l'API windows (à que je l'aime celle là).
C'est à dire avec une CallBack et la librairie "Windows.pas".
Tu aura un Entry Point et une CallBack genre :
function WndProc(hWnd : HWND; Msg : UINT; WParam : WPARAM; LParam: LPARAM): UINT; stdcall;
begin
case Msg of
WM_COMMAND:
begin
bla bla
end;
WM_DESTROY:
begin
bla bla
end;
end;
Result := bla bla;
end;
et il faudra créer tes fenêtres non pas via l'editeur mais en les programmant avec l'API "CreateWindow" etcc... et çà sera a toi de gérer les messages du système pour intercepter les cliques et autres événements de tes composants via non pas leur nom mais leur Handle :-)
Je sais c'est plus chaud a programmer mais ton executable peut atteindre la taille record de 30 Ko !
Si je trouve le temps je ferai une source de démonstration, mais en cherchant sur CodeSource çà doit se trouver sans problème.
Merci à vous. Pour Form je vais voir si je peux pas m'en débarasser. C'est pas grave que la taille de l'executable soit importante mais j'étais surpris. A ce tarif là autant ne pas faire d'appli console lol. On y gagne pas grand chose