CAPTURER L'ARBORESCENCE DES DOSSIERS PAR RÉCURSIVITÉ INDIRECTE
JulioDelphi
Messages postés
2226
Date d'inscription
dimanche 5 octobre 2003
Statut
Membre
Dernière intervention
18 novembre 2010
-
8 déc. 2004 à 15:59
ni69 Messages postés 1418 Date d'inscription samedi 12 juin 2004 Statut Membre Dernière intervention 5 juillet 2010 - 24 sept. 2005 à 11:32
ni69 Messages postés 1418 Date d'inscription samedi 12 juin 2004 Statut Membre Dernière intervention 5 juillet 2010 - 24 sept. 2005 à 11:32
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/28071-capturer-l-arborescence-des-dossiers-par-recursivite-indirecte
https://codes-sources.commentcamarche.net/source/28071-capturer-l-arborescence-des-dossiers-par-recursivite-indirecte
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