Programme avec nombreuses écritures disque... Est-ce ok ?
Résolu
Lus0rius
Messages postés
26
Date d'inscription
Statut
Membre
Dernière intervention
-
Lus0rius Messages postés 26 Date d'inscription Statut Membre Dernière intervention -
Lus0rius Messages postés 26 Date d'inscription Statut Membre Dernière intervention -
A voir également:
- Programme avec nombreuses écritures disque... Est-ce ok ?
- Cloner disque dur - Guide
- Defragmenter disque dur - Guide
- Test disque dur - Télécharger - Informations & Diagnostic
- Chkdsk disque dur externe - Guide
- Nettoyage de disque - Guide
4 réponses
Bonjour,
C'est vrai que c'est dommage d'utiliser le disque pour des fichiers détruits immédiatement après. Le système écrit lui-même régulièrement des données sur disque, s'il y en a que quelques centaines par jour ça peut rester négligeable, mais au delà il faudrait éviter.
Tu peux créer tes fichiers dans un disque RAM. Sous POSIX ça existe de base, mais sous Windows je pense qu'il faut installer un driver spécifique pour gérer un disque RAM.
C'est vrai que c'est dommage d'utiliser le disque pour des fichiers détruits immédiatement après. Le système écrit lui-même régulièrement des données sur disque, s'il y en a que quelques centaines par jour ça peut rester négligeable, mais au delà il faudrait éviter.
Tu peux créer tes fichiers dans un disque RAM. Sous POSIX ça existe de base, mais sous Windows je pense qu'il faut installer un driver spécifique pour gérer un disque RAM.
Bonjour
ce que tu peux essayer de faire c'est conserver une (ou des) preuve de changement du fichier xml (date de modification, taille, hash md5 ou autre) et ne pas réécrire le fichier bin si le xml n'a pas changer.
Si tu connais le format bin, tu peux aussi essayer de te passer du logiciel en ligne de commande en exportant directement depuis ton logiciel VB.Net. En effet, utiliser un logiciel c'est aussi un accès disque (en lecture c'est sûr mais peut-être aussi en écriture) et ça à chaque fois que tu le lances.
ce que tu peux essayer de faire c'est conserver une (ou des) preuve de changement du fichier xml (date de modification, taille, hash md5 ou autre) et ne pas réécrire le fichier bin si le xml n'a pas changer.
Si tu connais le format bin, tu peux aussi essayer de te passer du logiciel en ligne de commande en exportant directement depuis ton logiciel VB.Net. En effet, utiliser un logiciel c'est aussi un accès disque (en lecture c'est sûr mais peut-être aussi en écriture) et ça à chaque fois que tu le lances.
Justement, je ne connais pas le format .bin qui est un format propriétaire (enfin je crois), c'est pour ça que je suis obligé de passer par le logiciel de conversion fourni pas les créateurs du format.
J'ai réussi à contourner mon problème (voir mon message plus bas), mais ton idée de garder la date aurait été utile, merci !
J'ai réussi à contourner mon problème (voir mon message plus bas), mais ton idée de garder la date aurait été utile, merci !
yg_be
Messages postés
23541
Date d'inscription
Statut
Contributeur
Dernière intervention
Ambassadeur
1 583
bonjour,
tu t'inquietes d'user le disque ou de consommer trop d'électricité?
quel serai le nombre de fichiers traités pas jour, en moyenne?
tu t'inquietes d'user le disque ou de consommer trop d'électricité?
quel serai le nombre de fichiers traités pas jour, en moyenne?
Je m'inquiète surtout d'user le disque. C'est un explorateur de fichiers, donc le nombre de fichiers traités dépend de l'utilisateur. Mais il peut y avoir jusqu'à une 50aine de fichiers .bin dans un dossier, et le programme les traite un par un à chaque fois qu'on accède au dossier (même si on le quitte et y revient juste après). Il y a peut-être une optimisation à faire là-dessus...
Finalement, j'ai résolu mon problème en le contournant. Je me suis rendu compte que, malgré que les fichiers d'origine .bin soient encodés de manière à empêcher la lecture, les informations qui m'étaient nécessaires sont lisibles en clair. Donc, la conversion n'est en fait pas nécessaire, j'ai gagné en temps et il n'y a plus besoin d'écrire des fichiers sur le disque.
Sinon, j'avais aussi pensé à ne convertir les fichiers qu'une seule fois par session et de les supprimer à la fermeture du programme, ce qui aurait déjà limité le nombre d'écritures.
Sinon, j'avais aussi pensé à ne convertir les fichiers qu'une seule fois par session et de les supprimer à la fermeture du programme, ce qui aurait déjà limité le nombre d'écritures.
Enfin, j'ai réussi à contourner mon problème (voir mon message plus bas). Mais ton astuce pourra peut-être me resservir plus tard...