Vitesse d'exécution et écriture de fichiers

Bonjour,

J'ai un programme qui remplit environ 3000 fichiers texte pour un total d'un peu plus de 100Mo.

Jusqu'ici, ma méthode de remplissage n'était pas optimisée : en fonction de la valeur d'une variable, le programme ouvrait le bon fichier, ajoutait la ligne avec les valeurs qu'il avait déterminées, puis fermait le fichier. C'est très lent... et pas optimisé, puisqu'un même fichier peut être ouvert et fermé plusieurs centaines de fois.

Du coup, j'hésite entre deux méthodes :

- stocker les données à écrire dans des variables (collection contenant une chaîne ou un tableau pour chaque fichier, par exemple) pour n'ouvrir, écrire, et fermer les fichiers qu'en fin de programme, ou alors lorsque la longueur des données stockées en variables dépasse un certain seuil.

- ouvrir chaque fichier la première fois que le programme en a besoin, laisser le programme écrire dedans au fur et à mesure, puis refermer tous les fichiers en fin de programme.

Le réseau sur lequel travaille ce programme est très très lent. D'après-vous, quelle serait la méthode la plus rapide ?
Question subsidiaire : le FSO est-il compatible avec Excel 2003 ?

En vous remerciant d'avance pour vos réponses.
Cordialement,

Bonjour à toi,

Pour moi l'ouverture en début et au fur à mesure puis fermeture à la fin est assez risqué.
Si jamais il y a une micro-coupure réseau ça va être le bazar !

Je te conseil plutôt la deuxième méthode.
Traitement global, avec regroupement si possible des données directement par fichier puis écriture à la fin donc ouverture du fichier écriture de toutes les données puis fermeture et fichier suivant.
Tu peux utiliser des collection ou des dictionary pour stocker tes données tu ne devrais pas avoir de problème de taille.

Bonjour,
personnellement j'opterais pour un solution intermédiaire!

j'utiliserait la méthode Append de fso car écrire ligne par ligne va entraîner des accès disck et ralentir ton traitement!

si tu charge la totalité de ton fichier dans une viable tu est à la merci de l'ocupation mémoire!

de toute les façons, avoir 10 lignes ou rien dans un fichier qui devrait en contenir 10 000 pour l’utilisateur final?

tu charges 1000 dans un variable, tu écris sur le disck; tu vide ta variable!

En plus en utilisant le variables d'environnement tu peux sauvegarder ton fichier dans temp et transvaser le tout un fois terminé!

Bonjour !

Citation:

---

Envoyé par Z20500

Question subsidiaire : le FSO est-il compatible avec Excel 2003 ?

---

Oui, il est même référencé dans l'aide VBA interne !

Si c'est juste pour un Append, tu peux t'en passer, VBA disposant déjà de tout le nécessaire …
Tout comme pour parcourir les fichiers, la fonction Dir du VBA pouvant s'avérer plus rapide !

______________________________________________________________________________________________________
Je suis Paris, Charlie, Bruxelles, …

Bonjour

je suis d'accords avec marc

un test avec dir sur le fichier
l'ouvrir avec open en append (fonction vba interne avec argument 8 si je ne me trompe pas pour append )
et retranscrire toute les ligne d'un coup dans le fichier
fichier par fichier

edit :correction l'argument 8 c'est pour le FSO
avec la fonction interne c'est

Code:

---

1 2	dim x=freefile open cheminfichier for append as X ' x represente freefile

---

Bonjour,

Merci pour vos réponses.
Actuellement, le programme ouvre un fichier, écrit une ligne dedans avec

Code:

---

1 2 3

open Fichier for append as X print X, Ligne à écrire close X

---

puis ferme le fichier, ouvre un autre fichier, écrit une ligne dedans, le ferme, etc...
Cela a pour conséquence que le programme peut ouvrir un fichier et le fermer des centaines de fois au cours de l'exécution de la procédure.
Les fichiers sont écrits sur le disque puis ensuite transférés sur le serveur, mais le tout prend très longtemps.

En fait, je me demandais s'il valait mieux :
1) que le programme ouvre chaque fichier lorsqu'il en a besoin, écrive dedans au fur et à mesure, et ferme tous les programmes à la fin, ce que cerede2000 m'a déconseillé en raison des risques de micro-coupures. Il aurait fallu passer par le FSO car j'ai 3000 fichiers, la méthode open... for n'en permet que 255.
Je pourrais écrire sur le disque et tout retransférer ensuite, c'est ce que je fais déjà, mais le transfert en fin de procédure est lent (à priori 5-10 minutes sur 30 minutes à 1h). Ceci dit, transférer les fichiers une fois terminés ou écrire sur le serveur directement avec la deuxième méthode, revient peut-être au même.

2) inscrire le contenu à écrire dans les fichiers dans des collections de variables, (une variable par fichier) puis écrire à la fin, dans chaque fichier, au moyen de :

Code:

---

1 2 3

open X for binary as X Put X, Lof(X) +1, variable close X

---

Si Print marche pour écrire plusieurs lignes (j'avais compris que non, mais peut-être cela fonctionne-t-il avec des lignes séparées par Vbcrlf au lieu de chr(10) ?) , je passerais par Append ça serait plus simple et plus rapide, n'ayant pas besoin de récupérer la longueur du fichier.

Je crains cependant d'occuper la mémoire significativement avec cette méthode, et de ralentir la machine, ce dit également Rdurupt, ce pourquoi je pensais, comme il le propose, mesurer la longueur des données stockées en mémoire, et lorsqu'elle dépasse un certain seuil, provoquer l'inscription des données dans les fichiers et purger la mémoire. C'est un peu plus compliqué à faire par contre :oops:

Bonne soirée,

bonsoir
je fait du vbs et du html dynamique par vba ce qui représente des fichiers avec beaucoup de ligne et je le fait en une fois on est loin d'utiliser autant de mémoire que tu crois


a moins que tu travaille avec un Mo5 Visual basic 1.0 avec 64 k de mémoire vive au quel cas il est temps de changer de bécane

Bonjour,
Si je préconise de fractionner le fichier c'est parce que j'ai rencontré le problème.

Un boucle de 0 a l'ironie, peut ce se décompose en pas de 1024 (1K) .if i mod 1024= 0 then Appand: Purge!

Bien évidemment en fin de boucle il faut tester la valeur résiduelle de la string qui pourrait fait moins de 1024!

Bonjour, merci pour vos réponses.
J'ai opté pour la méthode de l'écriture fractionnée, ça marche plutôt bien pour le moment.

Bon week-end