Oui j'ai remarqué et je t'en remercie. Il est vrai, pour ce qui concerne la documentation, je m'améliore en ChatgptRe,
@crocrocro
Regarde la pièce jointe 1205117
W10 64 BITS / 365 64 BITS
@dysorthographie
Je suis avec assiduité toutes tes interventions concernant SQL sur XLD.
Function WinDir(ParamArray valeurs() As Variant) As Variant()
Dim I As Integer, Whr As String
Dim bm As New cBenchmark
' Initialisation de la requête SQL pour sélectionner les colonnes souhaitées
Sql = "SELECT System.ItemName, System.ItemPathDisplay, System.DateModified, System.Size FROM SYSTEMINDEX"
For I = 0 To UBound(valeurs) ' Boucle à travers les paramètres fournis pour construire la clause WHERE
Whr = Whr & " " & valeurs(I) ' Concatène chaque paramètre dans la clause WHERE
Next
If Trim(Whr) <> "" Then Sql = Sql & vbCrLf & "WHERE " & Whr ' Si la clause WHERE est définie, elle est ajoutée à la requête SQL
Debug.Print Sql ' Affiche la requête SQL dans la fenêtre d'exécution pour débogage
bm.TrackByName "Init Windir"
With CreateObject("ADODB.Connection") ' Crée une connexion ADODB et ouvre la connexion à l'indexeur de recherche Windows
.Open "Provider=Search.CollatorDSO;Extended Properties='Application=Windows';" ' Ouvrir la connexion
' Exécute la requête SQL et stocke les résultats
ReDim WinDir(0) ' Redimensionne le tableau pour les résultats
With .Execute(Sql)
If Not .EOF Then WinDir = .getrows ' Si des résultats existent, les place dans le tableau WinDir
.Close ' Ferme le recordset
End With
.Close ' Ferme la connexion
End With
bm.TrackByName "Execute Windir"
End Function
IDnr | Name | Count | Sum of tics | Percentage | Time sum |
0 | Init Windir | 1 | 281 | 0,09% | 28 us |
1 | Execute Windir | 1 | 305 342 | 99,91% | 31 ms |
TOTAL | 2 | 305 623 | 100,00% | 31 ms | |
Total time recorded: | 31 ms |
Il n'était pas tout seul dans le bateau, le patrick, notamment pour Windir, posté par @dysorthographie.entre les différentes méthodes de recherche de patricktoulon
Hello Staple1600Bonjour le fil
@jurassic pork
Merci pour le lien cBenchmarck
Je vais voir ce que cela donne sur mon PC
Name | Count | Sum of tics | Percentage | Time sum |
---|---|---|---|---|
Init Windir | 1 | 4 654 | 0,05% | 465 us |
Execute Windir | 1 | 8 735 420 | 99,95% | 874 ms |
TOTAL | 2 | 8 740 074 | 100,00% | 874 ms |
Total time recorded: | 874 ms |
IDnr | Name | Count | Sum of tics | Percentage | Time sum |
0 | Init Windir | 1 | 148 | 0,05% | 15 us |
1 | Execute Windir | 1 | 312 377 | 99,95% | 31 ms |
TOTAL | 2 | 312 525 | 100,00% | 31 ms | |
Total | time recorded: | 31 ms |
Une coincidence ?Si je teste (sans charger TB sur une feuille, ce que je faisais dans le test précédent), j'obtiens le même total pour le Time sum que toi.
C'est bizarre, non ?
IDnr Name Count Sum of tics Percentage Time sum 0 Init Windir 1 148 0,05% 15 us 1 Execute Windir 1 312 377 99,95% 31 ms TOTAL 2 312 525 100,00% 31 ms Total time recorded: 31 ms
(Car on n'a pas la même configuration, ni le même nombre de classeurs sur nos PC)
Ou alors il y a un truc qui m'échappe
Sub test_simple()
Dim TB()
TB = WinDir("SCOPE='file:D:\Dev'", "AND System.FileExtension = '.xlsm'")
End Sub
Dim TB()
TB = WinDir("SCOPE='file:D:\'", "AND System.FileExtension = '.dll'")
End Sub
IDnr | Name | Count | Sum of tics | Percentage | Time sum |
0 | Initialisations | 1 | 143 | 0,00% | 14 us |
1 | Slept | 2 | 1 005 527 | 17,56% | 101 ms |
2 | Finished loop | 1 | 94 675 | 1,65% | 9,47 ms |
3 | Waited | 1 | 4 624 944 | 80,78% | 462 ms |
TOTAL | 5 | 5 725 289 | 100,00% | 573 ms | |
Total time recorded: | 573 ms |
- Il doit s’agir du moyen le plus rapide et le plus précis possible de chronométrer le code VBA, c’est-à-dire avec le moins de surcharge possible.
- Lorsque le code est en cours d’exécution, la seule chose que fait cette classe est de stocker les horodatages. Tout traitement est retardé jusqu’à la fin de l’exécution du code.
- La seule meilleure méthode que l’utilisation de QueryPerformanceCounter serait de lire le TSC directement avec RDTSC, ce qui nécessite un .dll personnalisé - et un peu plus complexe.
- L’utilisation d’un UDT au lieu de Currency ou LongLong comme type de données de la fonction QPC peut être plus rapide que le retour d’un LongLong ou d’un Currency, mais le stockage/la gestion de cette valeur de retour dans VBA est loin d’être plus rapide qu’une simple valeur LongLong ou Currency. Probablement parce que VBA a besoin de stocker deux valeurs distinctes (partie basse et partie haute), au lieu d’une seule grande. Comme LongLong n’est disponible que sur les systèmes 64 bits et qu’il ne semble pas y avoir de différence de vitesse (entre ces deux types de données), Currency est la meilleure option.
Effectivement l'ai refait des essais cela serait plutôt 430 ms et pour la V2 ça varie sérieusement de 863 ms à 269 ms . La première fois que je lance c'est la plus lente. Un effet de cache ou de dll chargées ?bonjour @jurassic pork , @Staple1600 et tout les autres
@jurassic pork perso j'ai un doute sérieux de tes résultats
en effet tu dis
Recherche V2: 481 ms
Recherche V3: 239 ms
la v2 (shell +ligne de command vers fichier text)
et la v3 FSO
il n'y a pas photo la FSO devrait être loin derrière même pour 165 fichiers
en tout cas sur mes 3 pcs et les 7 pc au boulot la V3 fso est toujours plus lente
et là tu me dis que la FSO met moins de la moitié du temps de la v2
c'est tout bonnement impossible a mon avis même si elle est bien accélérée par le jumping
je peut me tromper mais bon
Ben c'est un peu normal tu n'as pas la même configuration d'ordinateurRe
@jurassic pork
Bizarrement si je teste la procédure de test sur github : Sub testCBenchmark()
Je n'obtiens pas les mêmes résultats que sur le site.
Que veux-tu faire de ces fichiers ? dedans il n'y a pas les résultats de la requête mais plutôt de quoi la relancer ( à mon avis ) ou alors le moyen de retrouver ces résultats qui sont cachés quelque part.Avec Windows Search (manuellement), on peut enregistrer le résultat de ses recherches.
On obtient alors un fichier *.search-ms stocké dans C:\Users\STAPLE\Searches
Exemple pour EXCEL
Fichiers EXCEL.search-ms qui est en fait un fichier XML
(qui contient des éléments qu'on a utilisé dans le code VBA)
En même temps, c'est logique.
Ma question : Est-ce qu'on peut utiliser ces fichiers en VBA ?
(sans passer par un Shell pour les ouvrir)
Chatgpt à dit:Oui, il est possible que le temps de traitement diminue après une première utilisation grâce à des mécanismes de cache ou d'optimisation. Dans le cas du fournisseur Search.CollatorDSO de Windows, voici comment cela pourrait se produire :
1. Cache du système : Windows peut conserver certains résultats en mémoire après une première requête pour accélérer les recherches ultérieures sur des fichiers ou des données similaires. Le cache des données fréquemment utilisées permet au système de répondre plus rapidement.
2. Indexation optimisée : Le service d'indexation de Windows est conçu pour améliorer la performance des recherches. Si un fichier ou un répertoire est déjà indexé, la requête suivante sera beaucoup plus rapide, car elle n'aura pas à parcourir physiquement les fichiers, mais utilisera l'index déjà créé.
3. Mise en cache des résultats : Certains systèmes ou services peuvent également mettre en cache les résultats d'une requête pour une utilisation future, réduisant ainsi le temps nécessaire pour une deuxième requête identique ou similaire.
En résumé, après une première requête, si les fichiers demandés sont déjà dans l'index ou si le système a mis en cache certaines informations, la requête suivante sera traitée plus rapidement, même si vous ne gérez pas explicitement le cache.