FILESYSTEMLIBRARY, TOUT (+ QUE FSO) SUR LES FICHIERS/DOSSIERS/DISQUES

Commentaire de violent_ken le 22/04/2007 15:12:40

Je sais que c'est pas vraiment optimisé...


Donc si vous avez LA MOINDRE IDEE POUR OPTIMISER CE CODE, merci d'en m'en faire part !

Merci, @+ ;)

Commentaire de violent_ken le 22/04/2007 16:01:36

C'est vrai que c'était assez long... ;)



Enfin le problème c'est que ce n'est pas assez rapide.
L'appel à GetDrive() pour mon HDD contenant Windows met... 1.5 secondes !!
Bon ok, toutes les infos sont récupérées mais quand même, ce temps est énorme !

De même pour les fichiers, 500 fois GetFile() met quand même 800 ms... beaucoup plus que FSO.


Y a moyen d'optimiser en ne récupérant qu'une seule fois le handle des objets, mais par contre faudrait mettre plusieurs fonctions/APIs/ENUM dans les objets...

@+

Commentaire de MadM@tt le 22/04/2007 17:17:17

Nooonn à ce point la ! Effectivement c'est bien mieux avec for each

Commentaire de violent_ken le 23/04/2007 17:48:38

thx EB ;) (si tu as des idées pour optimiser la vitesse...^^)


J'ai refait quelques tests : GetDrive ne met aujourd'hui plus que 200ms... je vois pas du tout pourquoi hier c'était 1500 ??

Et de plus, quand on fait un GetFile, un GetDrive ou un GetFolder avec FSO, AUCUNE info n'est récupérée...c'est quand on fait GetFile().PROPERTY que l'info est récupérée !

Donc normal que ce soit beaucoup plus rapide...puisque çà ne récupère pas d'infos !!



Je vais faire des benchs comparatifs réels d'obtention d'infos entre FSO et cette source.

@+

Commentaire de violent_ken le 23/04/2007 17:58:31

Ah bah bravo FSO....


Je viens faire le test de récupération des infos sur un fichier avec FSO vs cette source...

Pour la récupération de 500*22 infos, ma source est plus rapide de 50%... Et en plus, quand on fait .GetFile avec cette source, on récupère BEAUCOUP PLUS d'infos qu'avec le GetFile de FSO....

Autrement dit cette source est vraiment plus rapide, même si effectivement un bête ".GetFile().Size" sera plus rapide avec FSO (car ne récupère que la Size avec FSO, et récupère tout avec ma source).


Pas sur d'être très clair...


Je fait les tests avec les classes Drive et Folder...

@+

Commentaire de violent_ken le 23/04/2007 18:20:56

Cette source récupère des infos 50% plus vite que FSO sur les dossiers !


Par contre elle est beaucoup, beaucoup plus lente sur les accès aux infos sur les disques... Je vais essayer de réparer un peu çà en ne récupérant qu'une seule fois le handle avec CreateFile.

Mais je crains que l'écart de temps sur les disques demeure vraiment élevé...

@+

Commentaire de violent_ken le 23/04/2007 18:33:54

Ah oups, j'avais pas vu ton msg entre les miens ^^

Effectivement, c'est plus logique que les properties ne récupèrent pas elles-même les infos (enfin je crois) ! Laissons çà aux functions ^^


Par contre, gros problème encore avec les Drives/Disks. J'espère que c'est l'appel à CreateFile() pour récupérer le handle du drive qui est très lent, parce que sinon je vois pas trop comment optimiser...



A ton avis, est ce grave d'avoir un handle du disque "ouvert" durant toute la vie d'une variable de type Drive ou PhysicalDisk ??
Parce si c'est pas grave, je récupère une seule fois le handle dans le Class_Initialize du Drive/PhysicalDisk, je le stocke en private (et éventuellement je le propose en Property Get) et ensuite j'appelle des fonctions déclarées en Friend dans FileSystem avec comme paramètre le handle du disque ==> gain de 5 ou 6 appel à l'API CreateFile par GetDrive.

A ton avis, c'est une bonne idée ou pas ??

@+

Commentaire de violent_ken le 23/04/2007 19:02:40

"attention a ne pas trop stocker ! car si on insert un disque amovible la classe ne le detecte plus..." ==> J'avoue que j'ai pas trop saisi ??

@+

Commentaire de violent_ken le 23/04/2007 19:10:20

Ah ok, effectivement !


Alors le meilleur compromis serait-il de faire :
- CreateFile une fois lors du RefreshInfos de la classe Drive
- récupérer les infos par des fonctions Friend de FileSystem avec le handle en param
- CloseHandle à la fin de la sub RefreshInfo
?


Autre chose pendant que je t'ai sous la main ^^ ==> sais tu comment cacher la classe clsDef pour le projet utilisant la dll ?

Merci, @+

Commentaire de violent_ken le 23/04/2007 19:55:57

En fait, cette classe contient les types et les enums publics... donc pas moyen de la mettre en private !

@+

Commentaire de violent_ken le 23/04/2007 20:45:04

Ok, je me renseigne sur les typelibs ;)
Merci, @+

Commentaire de violent_ken le 24/04/2007 15:14:14

MAJ 2 :

- suppression de certains enum en double
- suppression de la classe clsDef qui était VRAIMENT inutile
- suppression des déclarations de constantes et de variables inutiles
- suppression d'un bug énorme dans GetDriveVolumeInformation_HANDLE ==> retour à la version son _HANDLE ==> "seulement" un gain de 65% de temps par rapport à la version 1


@+

Commentaire de Renfield le 24/04/2007 15:51:37 administrateur CS

Pas simple a compiler l'exe, la scripting runtime est repassée au dessus de ta lib, dans les priorités... (merci vb^^)

Commentaire de violent_ken le 24/04/2007 16:03:59

Voilà c'est bon, plus de référence douteuse à Scripting et en même temps j'ai viré un bug sur strDriveType/DriveType de la classe Drive.

@+

Commentaire de us_30 le 24/04/2007 21:38:34

Bonsoir,

Impresionnant ! Je regarderai en détail ce week-end. Bravo 10/10 !

Amicalement,
Us.

Commentaire de MadM@tt le 24/04/2007 22:25:11

Tain le boulot fournit est balèze !

Pour les fonctions d'encryption tu utilise quel système de cryptage ?

Commentaire de us_30 le 24/04/2007 23:29:32

Re-salut à tous,

J'ai pas trop résisté, j'ai jetté un petit coup d'oeil, tout de même... Pour l'instant j'ai vu qu'une simple coquille dans info lecteur, pour le calcul en pourcentage de libre. Cela renvoi le pourcentage occupé à la place... ah ! -);

Sinon, en présentation tu demandes aussi des idées de fonction... Il me semble (sauf erreur) que tu n'as pas de fonction de recherche de fichier, de dossier, avec le critère nom ou avec le contenu, comme dans l'exploreur... voir avec n'importe quel critère (ou presque) par exemple, la date de création, d'accès, etc... enfin, bon on peut aller loin comme ça... voir en combinaison de critères (multi-critères). Exemple, avec la date de création et contenant tel info... Long programme...

Il y a pas longtemps, il me semble également que tu avais codé un "Broyeur de fichier", je ne crois pas l'avoir vu dedans. A rajouter si c'est bien le cas, enfin c'est une idée.
A noter, que j'avais fait également une fonction similaire (peut-être encore plus élaborée, mais qu'en VB donc beaucoup moins rapide) pour effacer toute trace d'un fichier, certes, mais il me sert après un cryptage de fichier. En effet, il est un peu bête de crypter un fichier, si sa forme non cryptée est seulement effacé par un simple DELETE... De plus, pour des fichiers déjà éffacés (delete), il est intéressant de pouvoir aussi "broyer" leurs traces. Donc, j'avais aussi codé un remplissage jusqu'à saturation du disque, (avant effacement). Après essai par plusieurs programmes de type FileRecovery, on peut constater qu'ils ne peuvent plus rien retrouver... donc, voici une idée... mais bon, c'est très spécifique, j'en conviens... De plus dans le volume où windows garde son fichier d'échange, on ne peut pas tout faire... voir si on peut faire mieux...

Voilà, déjà...
Amicalement,
Us.

PS : EBArtSoft : On peut aussi avoir petit et rapide...

Commentaire de violent_ken le 25/04/2007 13:06:33

EB ==> lol !!


Sinon, effectivement, la recherche de fichiers/dossiers n'est pas inclue, il n'y a qu'un listing des fichiers/dossiers qui est possible.
Pour l'utilitaire d'effacement des fichiers, j'avais pensé à l'inclure, mais je me suis dit que çà allourdirait quelque peu la classe pour une utilisation au finale assez rare.


Je vais y réfléchir, voir si c'est pas trop lourd à inclure, mais déjà merci pour ces propositions ! (et merci également pour avoir signalé le bug que je corrigerai ce soir).

@+

Commentaire de violent_ken le 26/04/2007 20:53:40

Ah oui, je vois l'optimisation, c'est sur que l'on y gagne (car plus d'appel à une Function et donc pas d'attribution des valeurs aux param en byref).

"En faisant (P/10000) * B au de (P*B)/10000 on multiplie..." ==> exact... j'essaie de le prendre en compte dans mes codes pour éviter l'overflow, c'est une erreur de ne pas l'avoir mis !

Merci pour ce commentaire constructif.
Je vais faire une MAJ ce soir je pense (correction de bugs, optimisations et ajout de nouvelles fonctions).

us_30 ==> Finalement je ne mettrais pas la sanitization, car trop lourd à mon gout (ASM de EB...etc).

@+

Commentaire de violent_ken le 26/04/2007 20:58:40

Erf, je suis trop bête...

Dsl pour ce triple post...
@+

Commentaire de violent_ken le 26/04/2007 21:08:44

lol ;) C'est pas la taille le problème^^

C'est entre autres le fait qu'il faille rajouter une classe (que d'ailleurs je ne sais pas masquer pour l'utilisateur !) et quelques centaines de lignes pour la sanitization, les fonctions Friend prenant un param un pointeur...etc.

Puis "la" grosse question est : est-ce raisonnable de mettre ce bout de code somme toutes dangereux et d'une utilisation relativement rare dans une library qui a pour objectif de remplacer FSO "au quotidien" (enfin perso :p) ??


Peut être que oui en fait...je sais pas trop...

En disant "moi je l'ajouterais...." tu vas finir par me le faire mettre dedans ! lol

@+

Commentaire de Galain le 26/04/2007 21:19:36

Salut à tous

Pour Violent_Ken la valeur 1 en Currency est représentée sur 64 bits par la valeur 10000 équivalente en binaire : donc il faut diviser par 10000 pour retrouver la valeur binaire correcte 1 sur 64 bits et ensuite on multiplie cette valeur par Bytespersector pour avoir le pointeur sur le premier octet à lire ou écrire  

Pour Eb : d'accord avec toi je l'ajouterai; cela ne mange pas de pain

A+ les gars

Commentaire de EBArtSoft le 26/04/2007 21:26:36 administrateur CS

C'est simple un bibliotheque de fonction sa sert a quoi ? Ca sert a etre simple et surtout exaustif ! Sinon autant ce taper des lignes de code et virer la lib ! Maintenant c'est dangereu alors je le met pas... dans ce cas la autant enlever toute les fonctions de vb car suffit d'utiliser "shell","kill" voir simplement New pour flinguer windows. Ce n'est donc pas la fonction qui est dangereuse mais la personne qui l'utilise. Enfin bref si c'est la "taille" ou la "complexite" d'un code qui te fait peur tu ne metras jamais rien de bien dans ta lib, ce qui fait la difference avec les autres lib pourri que personne ne telecharge telement il y en a des floppé c'est justement le fait qu'elle offre des fonction et des possibilites que les autres n'ont pas alors va y petit !!

hahah faut que j'arrete la coke :p

Commentaire de EBArtSoft le 26/04/2007 21:33:17 administrateur CS

classe->propriete->instancing->private

Commentaire de EBArtSoft le 26/04/2007 21:35:30 administrateur CS

Reponse question 2 : Voila ta compris !

Me dit pas que t'as jamais fait :

mavar = TextBox1

:p

Commentaire de EBArtSoft le 26/04/2007 21:42:52 administrateur CS

un pointeur de fonction ???? en vb ???? mais naaaan une interface et puis c'est bon ! regarde directx il a compris lui :p

Commentaire de violent_ken le 26/04/2007 21:57:35

Ma dernière question et puis j'arrête de flooder :p

Devrais-je ajouter des fonctions du genre :
-découpage/fusion de fichier
-création d'un fichier ISO depuis un lecteur CD/DVD
-comparaison de fichiers
-...etc

?
@+

Commentaire de violent_ken le 26/04/2007 22:08:55

Papa Renfield, c'est vrai ^^

Sinon t'as raison, une interface sera beaucoup plus "sure" pour l'user. Bien que probablement plus lente ?

@+

Commentaire de violent_ken le 26/04/2007 22:22:31

Erf ! Faudrait pas que ce soit le jour et la nuit quand même... paske si on appelle la procédure à chaque fichier trouvé, ou bien tout les 500 fichier scannés, çà va faire beaucoup de temps perdu  !

Et au fait, devrais-je de ton avis ajouter les autres fonctions citées précédemment ?
@+

Commentaire de violent_ken le 26/04/2007 22:50:01

Ok j'ajouterais tout...

Demain çà va coder sec ^^ (je vois déjà les 5000 lignes dans FileSystem.cls)
@+

Commentaire de violent_ken le 27/04/2007 21:47:41

Oui j'oubliais : j'ai ajouté aussi les propriétés FolderName (dans File) et DriveName (dans File et Folder).

Autre chose, j'ai oublié de remercier EB pour sa classe avec le code ASM dedans ^^

Encore une chose, j'ai laissé les déclarations des fonctions Search... dans FileSystem, elles ne sont pas faites, mais c'est prévu.


Dernière chose ==> je compte mettre plus tard (quand j'aurais le courage :p) la description de chaque fonction dans les attributs de procédure.
La question étant : en anglais ou en français ??


Enjoy, @+

Commentaire de Renfield le 28/04/2007 06:46:14 administrateur CS

idem, en british sera plus aisément distribuable

Commentaire de EBArtSoft le 28/04/2007 11:58:04 administrateur CS

Ahhhh bah ça commence à être interressant cette histoire :p

Commentaire de draluorg le 28/04/2007 13:10:28

Salut a tous,

J'ai enfin trouvé le temps de jetter un oeil a ta big class ^^
Bravo pour le fameux boulot!

Sinon cote optimisation j'ai vu des ptites choses du genre:
Do While hDrive <> INVALID_HANDLE_VALUE
         hDrive = CreateFile....      
        If hDrive <> INVALID_HANDLE_VALUE Then
            Call EnumPhysicalDisks....
        End If
Loop

Pourquoi ne pas faire directement
Do

    hDrive = CreateFile....      
    If hDrive = INVALID_HANDLE_VALUE Then exit do
    Call EnumPhysicalDisks....
loop

Bon je chipote je te l'accorde!

Autre point mais je ne suis pas sur a ce niveau la..
Quand dans une classe genre ClsFolder tu appel clsFile.kelkeschoses ca instance a chaque fois une nouvelle classe non ?
Si oui tu peux peut etre instancier une ClsFile dans le Class_Initialize et la supprimer dans le Class_Terminate et utiliser toujours celle la dans ta clsFolder... (perso c'est ce que je fais mais je sais pas si ca change grand choses)

Sinon je dirais aussi de faire une Tlb au moins pour les api les plus appelés.

En tout cas ta classe est vraiment sympa encore bravo!

++

Commentaire de draluorg le 28/04/2007 14:08:53

Oup's sorry autant pour moi j'avais pas vu que tu instanciais tes classes dans le Class_initialize!

Sinon pour le Do While oui en effet de cette facons tu es obligé de reverifier a chaque boucle! donc c'est pour ca que je dis autant ne pas mettre de while et sortir de la boucle des qu'on a un INVALID_HANDLE_VALUE...

Pour la tlb c'est un peu comme les #include en C/C++ mais bon je vais pas m'etendre sur ce sujet que je connais aussi tres peu!
En gros les avantages sont:
Jusqu'a 15 de gains sur l'APPEL a une fonction
Tes déclares ne sont pas dans ton projets mais dans un fichier de reference (fichier qui sera compiler avec le projet donc pas besoin de le distribuer avec ton exe)
Eb et RenField ont chacun déposé une source qui permet de les generer et pourront mieux t'expliquer que moi

++

Commentaire de violent_ken le 28/04/2007 14:20:38

Salut,

Seb ==> Exit Do, yep, bonne idée. Pour les tlb, je regarderai ! Si on gagne beaucoup de temps lors des appels aux APIs, çà peut valloir le coup de changer.

Galain ==>
-Attributs, pour GetFileAtributes ? Ok, je passerais cette variable de type FileAttributes (un enum plus explicite)
-FileCompressedSize ==> En fait, je pense que le mieux serait de décomposer GetFileSizes en GetFileSize et GetCompressedFileSize ==> évite tous les problèmes
-FirstSector ==> ok ;) C'est un exemple de lecture du premier secteur du disque. Mais comme il y a généralement des &h0 dans le début du disque (qui "coupent" la string), la textbox n'affiche que 2/3 caractères...

@+

Commentaire de violent_ken le 28/04/2007 16:21:26

Cà y est c'est bon...


Au programme de cette MAJ :

- ajout des fonctions GetFolderDateAsCurrency et GetFileDateAsCurrency
- ajout de la recherche de fichiers/dossiers multicritères.

Les critères possibles sont : taille, nom, dates (les 3).


Il faut remplir un type perso pour personnaliser sa recherche.
J'ai implémenté une interface pour la recherche ==> il existe deux "events", ItemFound et SearchIsFinished.

Pour en bénéficier, il faut mettre "Implements ISearchEvent" dans le code de la form...



Voilà un exemple de définition des critère de recherche (avec lancement de la recherche en récupérant un objet, avec l'utilisation de l'interface) :

    With MySearch
        .Criteria = SearchName + SearchSize + SearchDateLastAccessed
        .DateLastAccessedOperator = [ <= ]
        .DateLastAccessedValue = "24/04/2007 17:45:12"
        .SearchName = ".exe"
        .SizeOperator = [ > ]
        .SizeValue = 50000
        .RespectCase = True
        .SubFolder = True
        .FolderName = "C:\Program Files"
    End With
    
    Call FS.SearchForFiles(MySearch, True, Me)


La méthode de recherche est :
1) récupération de tous les fichiers (ou dossiers) avec un enum
2) test de chaque fichier (ou dossier) avec les critères ==> valide ou pas le fichier (ou dossier)


Galain ==> les attributs sont déjà définis en une classe. 32 est affiché dans la textbox, mais dans l'IDE, l'autocomplétion de propose de manière textuelle les différents attributs.


Pour l'interface, c'est peut être pas ce qu'il y a de plus propre, à vous de me le dire ^^


@+ (j'arrête pour aujourd'hui sauf si bugs...)

Commentaire de JLN le 30/04/2007 09:23:55

Super tu as réinventé la roue... Bon je plaisante, très bon code, mais quelle était l'idée de départ pour vouloir réencoder tout ca ? Je sais tout n'existe pas... Mais n'aurait-il pas mieux value ne s'occuper que de l'inexistant ? Sinon c'est du bon et on peut dire même du très bon code.

Bonne prog à tous...

@+ JLN

Commentaire de drissou le 30/04/2007 11:01:24

VIOLENT_KEN
Super tes classes.
je sui toujours bloqué car je n'ai pas eu le temps de modifer pour que cela focntionne sur Win 98, mais là n'est pas le problème..
je ne sais pas si cela t'intéresse, mais sur PSC il y a un prog pour détecter l'ajout ou la suppression de lecteurs
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?lngWId=1&txtCodeId=68456
peut être à ajouter pour avoir ce suivi

personnelement je n'ai pas testé non plus mais dans ce vaste projet que tu construis..
Drissou

Commentaire de JLN le 30/04/2007 11:58:42

Merci pour ta réponse, et en y repensant c'est vrai qu'il vaux mieux avoir qu'une seule librairie à utiliser dans une appli plutot que 2. Et je le redis c'est du bon boulot !

Bonne prog à tous...
@+ JLN

Commentaire de lokovbf le 18/05/2007 12:58:44

d'abord bravo pr ta classe:
ca va me servir ds mon job parfois le fso de m$ laisse à désirer
voici  qq suggestions à 1ere vue pr optimiser :  
désolé car facile de critiquer, pas eu trop le tps d'examiner ta dll ou de bien rédiger, et me trompe peut-etre ds mon analyse
=> A toi de voir...

- En general pr optimiser:
attention, ton syst est assez lourd (normal, vu l'ampleur de ton boulot.)
mai vb étant ultra-lent:  limite un max les encapsulages/intermerdiaires avant l'operation finale  (ta dll serait nickel en c/c++...)
Quitte à etre moins 'propre', à perdre qq fonctionnalités plus 2aires (car ta dll est suffisament riche)

=> un ex du pb:   on veut lire la prop de n répertoires
for each ... in ....
    Set cFol = FS.GetFolder(Path,true)  
    ... = cFol.DateCreated  <-- c'est ca qui interesse
next

0) set FS= new FileSystem  ' ok

1) FileSystem.GetFolder(Path) :
   Set GetFolder = New Folder  
   GetFolder.SetPath(Path, True) ' 1er intermedaire : ok

2) Folder.Class_Initialize
     Set clsFile = New FileSystem  ' RE-filesystem:  AIE!
3) Folder.SetPath(Path,true)
    MyFolder.Path = Path
    If RefreshInformations (<=true) Then Call RefreshInfos
4) RefreshInfos()
    clsFile.GetFolderDates_HANDLE   .GetShortPath .GetParentFolderName  etc... etc...
' AIE AIE: =>   N accès au disque.  tu extrait TOUTES les props dont je n'avais pas besoin et la, ca peut faire ramer

c'est pire avec la classe File ou on y rajoute des GetAssociatedProgram CompressedFileSize GetFileExtension etc...

je te file qq solutions ds les autres post
si tu fais evoluer ton code, ca m'interesse bcp.
bon courage et bravo