Microsoft 365 WindowsSearch & VBA + WSearch et PowerPivot

[Staple1600]

Bonjour le fil

Pour faire écho à la discussion de @patricktoulon, j'ai retrouvé ce fil

VBA et Windows Desktop Search...

[Résolu] - VBA et Windows Desktop Search... Bonjour le forum XLD, Je recherche des fichiers sur mon réseau professionnel avec la commande Application.FileSearch dans un répertoire contenant une arborescence de près de 12000 dossiers... La recherche d'un fichier prend souvent entre 1 et 2...

excel-downloads.com

J'ai voulu testé sur 365 et W10 64 bits
Et j'ai ce message d'erreur

Alors tout comme @patricktoulon , je vous invite à tester le code présent dans la discussion de 2013 citée plus haut

La question étant: est-ce que chez vous aussi ce message d'erreur apparait ?

EDITION: Voir le message#57 où apparait PowerPivot dans l'histoire.

 

[Staple1600]

Re,

@crocrocro

W10 64 BITS / 365 64 BITS

@dysorthographie
Je suis avec assiduité toutes tes interventions concernant SQL sur XLD.

 

[dysorthographie]

Re,

@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.

Oui j'ai remarqué et je t'en remercie. Il est vrai, pour ce qui concerne la documentation, je m'améliore en Chatgpt

 

[jurassic pork]

Hello,
j'ai effectué un test de performance (en utilisant cBenchmark) de windir avec les mêmes paramètres que ceux utilisés pour un test de performance entre les différentes méthodes de recherche de patricktoulon dans ses boîtes de dialogue de recherche :

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

Recherche de *.xlsm résultats 165 fichiers
Recherche V1: 0,97 s
Recherche V2: 481 ms
Recherche V3: 239 ms
Recherche V4: 111 ms (Recherche_PowerShell2 PowerShell lancé par l'intermédiaire d'une dll unmanaged Csharp)
Recherche V4 1: 1,12 s (Recherche_PowerShell PowerShell lancé par un WScript.Shell)
Recherche Windir: 31 ms

Ami calmant, J.P

 

[Staple1600]

Bonjour le fil

@jurassic pork
Merci pour le lien cBenchmarck
Je vais voir ce que cela donne sur mon PC.
EDITION:
Merci également pour la modification de Windir pour l'utiliser avec cBenchmark

Spoiler: (aparté Césarien)

entre les différentes méthodes de recherche de patricktoulon

Il n'était pas tout seul dans le bateau, le patrick, notamment pour Windir, posté par @dysorthographie.
Quand à moi, j'ai fait dans la suggestion d'emploi de PS et/ou de WSearch, initialement dans sa discussion.
Au point de créer cette discussion, curieux d'investiguer plus avant avec WSearch.
Je n'oublie pas les autres participants qui sont passés dans mon fil, et je remercie au passage.
(/aparté Césarien)

 

[jurassic pork]

Bonjour le fil

@jurassic pork
Merci pour le lien cBenchmarck
Je vais voir ce que cela donne sur mon PC

Hello Staple1600
L'installation de cBenchmark n'est pas forcément évidente il faut cocher en référence le Microsoft Scripting Runtime (à cause des dictionary).
Télécharger le fichier cBenchmark.bas, l'éditer dans un éditeur de texte.
Dans Excel créer un module de classe cBenchmark et coller dedans le contenu de cBenchmark.bas

 

[Staple1600]

Re

@jurassic pork
Merci pour les précisions, mais j'avais déjà coché (quand j'ai lu Dictionnary dans le code)
• Pour télécharger depuis Github, en cliquant sur
Puis ==> CTRL+A/CTRL+C => CTRL+V dans VBE
et c'était OK direct

Voici les résultats 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

C'est nettement moins bien que chez toi

PS: Est-ce que le fait d'avoir d'autres logiciels ouverts a une incidence ?
Et est-ce mieux de tester avec un seul classeur ouvert ?

 

[Staple1600]

Re, Bonjour @patricktoulon

@jurassic pork
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.

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​

C'est bizarre, non ?
(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

 

[jurassic pork]

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.

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​

C'est bizarre, non ?
(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

Une coincidence ?
avec ce test :

Sub test_simple()
Dim TB()
TB = WinDir("SCOPE='file:D:\Dev'", "AND System.FileExtension =  '.xlsm'")
End Sub

j'ai 31 ms
Avec ceci :
Sub test_simple()

Dim TB()
TB = WinDir("SCOPE='file:D:\'", "AND System.FileExtension =  '.dll'")
End Sub

j'ai 1,67 s

 

[Staple1600]

Re

@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.
Et toi ?

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​

Sinon avec C:\ et *.dll, j'obtiens
2,38 s

on peut lire en bas de page sur le site

• 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.

• Edge m'a traduit dans la langue de Molière, mais est-ce qu'un XLDien peut traduire en langage de tous les jours ?
• Celui que j'utilise pour parler avec ma boulangère quand je vais acheter mon pain aux graines de chia
• Non, je déconne, je mange du pain noir

 

[jurassic pork]

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

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 ?

 

[jurassic pork]

Re

@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.

Ben c'est un peu normal tu n'as pas la même configuration d'ordinateur

 

[Staple1600]

Re

[Aux lecteurs du fil]
Je vois qu'on arrive déjà à cinq pages dans cette discussion
Je viens d'échanger en MP avec patricktoulon, et comme @jurassic pork ne lit pas les MP, j'ai une suggestion en forme de désidérata que je publie dans la discussion.

On peut se focaliser ici sur VBA+WindowsSearch qui est le thème de ma discussion
et parler de la pseudo boite de dialogue de patrick dans sa discussion ?

C'est possible ? (Et sans que personne ne prenne la mouche ?)

Pour la volée de bois verts, commentaires en MP, svp
[/Aux lecteurs du fil]

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)

 

[Staple1600]

Re

@patricktoulon
Je suis passé à autre chose
Voir le message#63
Ici, je ne cherche plus à améliorer, je cherche à explorer une autre voie

PS: Pour info, le message#30, c'est moi qui l'ai posté
C'est dans le #31 que tu as repris le SCOPE posté dans le #30 et que j'avais testé pendant ta ballade.
(à moto si j'ai bonne mémoire)

 

[jurassic pork]

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)

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.

 

[dysorthographie]

Bonjour,

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.