ni69
Messages postés1418Date d'inscriptionsamedi 12 juin 2004StatutMembreDernière intervention 5 juillet 201012 24 sept. 2005 à 11:32
Mais grandvizir à Delphi3 ;)
hoby500
Messages postés86Date d'inscriptionmardi 25 février 2003StatutMembreDernière intervention26 mai 2019 24 sept. 2005 à 02:14
la routine :
function IncludeTrailing(const S: string): string;
existe déjà dans Delphi depuis le 5.0 au moins :
et elle se nommme :
function IncludeTrailingBackSlash(const S: string): string;
et il y a aussi
function ExcludeTrailingBackSlash(const S: string): string;
pour faire l'inverse
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 19 déc. 2004 à 21:49
Je crois que ça va être difficile de raccourcir encore. J'ai déjà épuisé toutes mes idées... mais si une me venait à l'esprit, alors je n'hésiterais pas à poster une idée N°3, sans les caractères spéciaux dans le nom des dossiers bien sur.
Merci de ton soutien fort sympathique. 8-))
JulioDelphi
Messages postés2226Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention18 novembre 201014 19 déc. 2004 à 21:44
merciiiiiiii
bon c bien mieux cette idee n°2, ce que je fais en 3300ms tu le fais en 3800ms !
ça c de l'optimisation :)
tu crois ke tu peux encore reduire ? c deja pas mal !
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 19 déc. 2004 à 21:24
Je suppose que c'est à cause de ton avantage de membre club avec le lien Télécharger. Ok, je te la remet tout de suite...
JulioDelphi
Messages postés2226Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention18 novembre 201014 19 déc. 2004 à 20:53
HAAAAAAAAAA
merci de reposter le zip sans les accents et caracteres speciaux (idee n2 au lieu de idée n°2) merciiiiiiii
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 18 déc. 2004 à 18:22
Finalement Sort est très utile... Le Zip comportant deux versions différentes du programme, précisons qu'il ne faudra garder que la version N°2. Elle offre plus d'avantages que l'autre version.
Au final, que ce soit lent ou non... pff! Après tout, il n'y a pas grande différence et la rapidité n'était pas le but recherché.
J'ai quand même fait un test empirique au chronomètre avec la version N°2 et je la trouve légèrement plus rapide que la version N°1 en mode roJulioDelphi. Ce fut pourtant un petite modif de rien du tout.
Enfin voilà... c'est super !
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 16 déc. 2004 à 19:45
Je réfléchissais cette semaine à truc. On dit dans ce code que les Items sont classés par groupe de dossiers ayant même niveau. Cela est lié à la fonction ~.Add. Mais pourquoi ne ferait-on pas ~.Insert. Ainsi, les items serait déjà ordonnés à la fin de la procédure et plus besoin de ~.Sort.
Je vais donc vous préparer tout cela pour bientôt...
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 11 déc. 2004 à 13:03
Ca permet juste de bien vider la RAM. Windows c'est comme les piles, il y a un effet mémoire. Si mémoire, alors expérience faussée !
Soit en forme pour rebooter 3 fois, sinon ça ne bootera pas... (private joke). Elle était bien bonne celle-là !
;)
JulioDelphi
Messages postés2226Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention18 novembre 201014 11 déc. 2004 à 12:26
cool, sinon j'ai pas compris ton system de reboot :/
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 11 déc. 2004 à 12:04
Considérons Program Files\ avec 50000 fichiers, 5 Go et 2300 dossiers.
J'ai reboot le PC pour faire mon test: GV 50 secondes, et JD 2 secondes. Mais en rebootant un petit coup et en refaisant le test JD, ça fait 20 secondes.
Il ne faut donc pas enchaîner les tests... De plus, ils confirment que c'est bien la fonction GetFileAttributes qui ralentissait tout. TStringList est donc tout à fait génial.
En conclusion: on gardera le mode roJulioDelphi car la syntaxe est la plus courte.
JulioDelphi
Messages postés2226Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention18 novembre 201014 11 déc. 2004 à 11:15
voila, j'ai fait les nouvelles comparaisons, je chope l'arborescence de mon c:\ (3496 dossiers pour 11.7 go de données à brasser) et voici le resultat en image :
donc l'option roGrandVizir fait rammer la procedure. garde une des deux autres :D
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 10 déc. 2004 à 18:28
Finalement, je l'ai mis à jour plus tôt. Tant mieux... Pour changer le mode, il suffit bêtement de modifier la valeur de RecOpts.
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 9 déc. 2004 à 17:51
Emandhal>
1) A vrai dire, je ne suis pas si sûr que cela vienne de la TStringList, car le code de JD en utilise aussi une et son code n'est pas autant plus lent.
2) De plus, les seules listes dans Delphi sont TStringList. Je m'étais amusé à faire une classe permettant de gérer des listes via un String, permettant alors d'avoir des listes de listes. Les performances étaient minables. Il faut dire que TStringList use à mort de l'ASM (un truc méga rapide).
3) De plus, un membre sur DelphiFr s'était amusé à comparer les listes de Delphi avec celle de C++. Il en sortirait que Delphi bat tous les records de performances.
Je pourrais juste ajouter que "DirSTL.Sort" peut-être un gadget. Par récursivité directe, DirSTL est classée correctement, càd que le dossier Alphonse\ et ses sous-dossiers sont regroupés. Dans mon code, les sous-niveaux sont groupés en fonction de leur profondeur. Si cette absence de classement ne pose pas problème, il est inutile de vouloir classer la liste. Si ~.Sort est répétée 20 fois, le temps s'allonge inévitablement.
Dans son code (ID=27000), JD utilise une syntaxe du type "if (SearchRec.Attr and faDirectory) <> 0 then" (un peu comme le modèle de MAURICIO). Cela est plus court que ma fonction IsDirectory que j'ai recyclé depuis FileCtrls.pas, et qui surtout appelle une fonction de Kernel >GetFileAttributes alors que l'utilisation de mon Recherche (=TSearchRec) aurait surement donné le résultat plus rapidement.
Je vais donc implémenter vos idées dans une MAJ, dispo si possible ce weekend. JD pourra alors nous présenter les nouvelles performances. Son commentaire était décisif quant au choix de la future méthode !
:))
Emandhal
Messages postés194Date d'inscriptiondimanche 2 mars 2003StatutMembreDernière intervention10 octobre 20063 9 déc. 2004 à 11:26
très très très interessant... bravo ;)
je pense que le fait que la fonction soit lente vient du fait que le code utilise une StringList. Il faudrai utiliser une autre technique utilisant moins de réallocations mémoire ce qui n'est pas le cas de la StringList.
cs_MAURICIO
Messages postés2106Date d'inscriptionmardi 10 décembre 2002StatutModérateurDernière intervention15 décembre 20145 9 déc. 2004 à 11:04
Très bon code!
Ça me rappelle mon projet MATRIX qui, à la maniere de l' explorateur de fichiers de Windows, montrait le contenu de tous mes CDs car j' y avais fait une image de l' arborescence dans une base de données ...
Sinon, voilà une fonction qui, je l' espère pourra t' aider:
function SEARCHREC_IS_DIRECTORY(SRec: TSearchrec) : Boolean;
begin
RESULT := ( SRec.Attr In [(SysUtils.faDirectory)..(SysUtils.faDirectory + SysUtils.faVolumeID + SysUtils.faSysfile + SysUtils.faHidden + SysUtils.faReadOnly)] )
Or ( SRec.Attr In [(SysUtils.faDirectory + SysUtils.faArchive)..(faAnyFile)] );
end;
cs_grandvizir
Messages postés1106Date d'inscriptionsamedi 8 novembre 2003StatutMembreDernière intervention 3 septembre 200622 8 déc. 2004 à 17:02
Pour calculer la mémoire, seul un prog qui cherche la RAM peut faire l'affaire. Ma carte mère m'a fourni ASUS Probe... On peut aussi utiliser le vu-mètre ressource.
Je suis étonné que ce soit plus long dans le processus !
Il n'est pas conseillé de mettre "Function RecurseSubFolder(Path: String): TStringList;", car si tu veux travailler la liste des résultats, il est nécessaire que tu ais justement une liste de créée. De plus, la fonction serait obligée de créer une liste et la détruire ensuite, après avoir rendu le résultat. Ce qui fait 2 listes.... Pas bon du tout !
Je regarderai la tactique de ton composant.
JulioDelphi
Messages postés2226Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention18 novembre 201014 8 déc. 2004 à 15:59
wow beau code tres propre (ça sens le vizir :D)
Comment calculer la comsommation memoire d'une proc ou d'un prog ? ça m'intersse beauicoup, c kler ke se rendre compte de la conso memoire peut aider a coder autrement.
sinon j'ai testé ma fonction (de mon composant TdbpFindFiles) et je mets 65millisecondes pour capturer l'arbo de c:\delphi7 (voir details ci dessous) et je mets 270 ms (minimum) avec la tienne. donc niveau rapidité c moins bon, mais si niveau memoire c meilleur alors selon l'utilisation c un code a garder (il est deja chez moi au chaud)
details :
Espace occupé total:
414 615 965 octets dans 5 202 fichier(s),
dans 314 répertoire(s)
je l'ai fait ensuite dans une boucle for de o à 19 (donc 20 fois de suite) et ça donne 1,374 secondes pour moi, et 6.095 pour toi... idem, il est possible ke je bouffe de la memoire, j'aimerais savoir comment cette info peut m'etre devoilée :D
sinon un ptit detail : ça serait bien d'en faire qqchose genre :
Function RecurseSubFolder(Path: String): TStringList;
pour pas qu'on ai a creer notre TS etc
24 sept. 2005 à 11:32
24 sept. 2005 à 02:14
function IncludeTrailing(const S: string): string;
existe déjà dans Delphi depuis le 5.0 au moins :
et elle se nommme :
function IncludeTrailingBackSlash(const S: string): string;
et il y a aussi
function ExcludeTrailingBackSlash(const S: string): string;
pour faire l'inverse
19 déc. 2004 à 21:49
Merci de ton soutien fort sympathique. 8-))
19 déc. 2004 à 21:44
bon c bien mieux cette idee n°2, ce que je fais en 3300ms tu le fais en 3800ms !
ça c de l'optimisation :)
tu crois ke tu peux encore reduire ? c deja pas mal !
19 déc. 2004 à 21:24
19 déc. 2004 à 20:53
merci de reposter le zip sans les accents et caracteres speciaux (idee n2 au lieu de idée n°2) merciiiiiiii
18 déc. 2004 à 18:22
Au final, que ce soit lent ou non... pff! Après tout, il n'y a pas grande différence et la rapidité n'était pas le but recherché.
J'ai quand même fait un test empirique au chronomètre avec la version N°2 et je la trouve légèrement plus rapide que la version N°1 en mode roJulioDelphi. Ce fut pourtant un petite modif de rien du tout.
Enfin voilà... c'est super !
16 déc. 2004 à 19:45
Je vais donc vous préparer tout cela pour bientôt...
11 déc. 2004 à 13:03
Soit en forme pour rebooter 3 fois, sinon ça ne bootera pas... (private joke). Elle était bien bonne celle-là !
;)
11 déc. 2004 à 12:26
11 déc. 2004 à 12:04
J'ai reboot le PC pour faire mon test: GV 50 secondes, et JD 2 secondes. Mais en rebootant un petit coup et en refaisant le test JD, ça fait 20 secondes.
Il ne faut donc pas enchaîner les tests... De plus, ils confirment que c'est bien la fonction GetFileAttributes qui ralentissait tout. TStringList est donc tout à fait génial.
En conclusion: on gardera le mode roJulioDelphi car la syntaxe est la plus courte.
11 déc. 2004 à 11:15
http://diabloporc.free.fr/comparaison.jpg
donc l'option roGrandVizir fait rammer la procedure. garde une des deux autres :D
10 déc. 2004 à 18:28
9 déc. 2004 à 17:51
1) A vrai dire, je ne suis pas si sûr que cela vienne de la TStringList, car le code de JD en utilise aussi une et son code n'est pas autant plus lent.
2) De plus, les seules listes dans Delphi sont TStringList. Je m'étais amusé à faire une classe permettant de gérer des listes via un String, permettant alors d'avoir des listes de listes. Les performances étaient minables. Il faut dire que TStringList use à mort de l'ASM (un truc méga rapide).
3) De plus, un membre sur DelphiFr s'était amusé à comparer les listes de Delphi avec celle de C++. Il en sortirait que Delphi bat tous les records de performances.
Je pourrais juste ajouter que "DirSTL.Sort" peut-être un gadget. Par récursivité directe, DirSTL est classée correctement, càd que le dossier Alphonse\ et ses sous-dossiers sont regroupés. Dans mon code, les sous-niveaux sont groupés en fonction de leur profondeur. Si cette absence de classement ne pose pas problème, il est inutile de vouloir classer la liste. Si ~.Sort est répétée 20 fois, le temps s'allonge inévitablement.
Dans son code (ID=27000), JD utilise une syntaxe du type "if (SearchRec.Attr and faDirectory) <> 0 then" (un peu comme le modèle de MAURICIO). Cela est plus court que ma fonction IsDirectory que j'ai recyclé depuis FileCtrls.pas, et qui surtout appelle une fonction de Kernel >GetFileAttributes alors que l'utilisation de mon Recherche (=TSearchRec) aurait surement donné le résultat plus rapidement.
Je vais donc implémenter vos idées dans une MAJ, dispo si possible ce weekend. JD pourra alors nous présenter les nouvelles performances. Son commentaire était décisif quant au choix de la future méthode !
:))
9 déc. 2004 à 11:26
je pense que le fait que la fonction soit lente vient du fait que le code utilise une StringList. Il faudrai utiliser une autre technique utilisant moins de réallocations mémoire ce qui n'est pas le cas de la StringList.
9 déc. 2004 à 11:04
Ça me rappelle mon projet MATRIX qui, à la maniere de l' explorateur de fichiers de Windows, montrait le contenu de tous mes CDs car j' y avais fait une image de l' arborescence dans une base de données ...
Sinon, voilà une fonction qui, je l' espère pourra t' aider:
function SEARCHREC_IS_DIRECTORY(SRec: TSearchrec) : Boolean;
begin
RESULT := ( SRec.Attr In [(SysUtils.faDirectory)..(SysUtils.faDirectory + SysUtils.faVolumeID + SysUtils.faSysfile + SysUtils.faHidden + SysUtils.faReadOnly)] )
Or ( SRec.Attr In [(SysUtils.faDirectory + SysUtils.faArchive)..(faAnyFile)] );
end;
8 déc. 2004 à 17:02
Je suis étonné que ce soit plus long dans le processus !
Il n'est pas conseillé de mettre "Function RecurseSubFolder(Path: String): TStringList;", car si tu veux travailler la liste des résultats, il est nécessaire que tu ais justement une liste de créée. De plus, la fonction serait obligée de créer une liste et la détruire ensuite, après avoir rendu le résultat. Ce qui fait 2 listes.... Pas bon du tout !
Je regarderai la tactique de ton composant.
8 déc. 2004 à 15:59
Comment calculer la comsommation memoire d'une proc ou d'un prog ? ça m'intersse beauicoup, c kler ke se rendre compte de la conso memoire peut aider a coder autrement.
sinon j'ai testé ma fonction (de mon composant TdbpFindFiles) et je mets 65millisecondes pour capturer l'arbo de c:\delphi7 (voir details ci dessous) et je mets 270 ms (minimum) avec la tienne. donc niveau rapidité c moins bon, mais si niveau memoire c meilleur alors selon l'utilisation c un code a garder (il est deja chez moi au chaud)
details :
Espace occupé total:
414 615 965 octets dans 5 202 fichier(s),
dans 314 répertoire(s)
je l'ai fait ensuite dans une boucle for de o à 19 (donc 20 fois de suite) et ça donne 1,374 secondes pour moi, et 6.095 pour toi... idem, il est possible ke je bouffe de la memoire, j'aimerais savoir comment cette info peut m'etre devoilée :D
sinon un ptit detail : ça serait bien d'en faire qqchose genre :
Function RecurseSubFolder(Path: String): TStringList;
pour pas qu'on ai a creer notre TS etc
8/10