6
votes

Comment obtenir la meilleure performance du streamwriter de .NET en C #?

Quelle est l'approche recommandée pour obtenir la meilleure performance lorsque nous devons créer des fichiers texte plus gros que 10 Mo?

Il existe plusieurs sections dans le code qui doivent écrire des choses à un seul fichier. Cela signifie beaucoup de lignes de texte.

Option n ° 1 (cette logique sera appelée à plusieurs reprises):

  1. Créer une instance de StreamWriter
  2. Écrivez des lignes (selon certaines logiques d'entreprise)
  3. Fermer l'instance de StreamWriter

    Option n ° 2:

    1. Créer un streamwriter au début du programme
    2. Écrivez toutes les lignes de différentes sections du code.
    3. Fermez le Streamwriter à la fin de la fin lorsque rien d'autre n'a besoin d'être écrit.

      option n ° 3: tout autre?

      N'oubliez pas que le fichier de sortie pourrait être plus grand que 10 Mo.


0 commentaires

4 Réponses :


16
votes

Tenir un seul écrivain ouvert sera plus efficace que l'ouverture et la fermeture répétées. Si ce sont des données critiques, cependant, vous devez appeler flush () après chaque écriture pour vous assurer qu'elle devient sur le disque.

Votre programme est-il multi-fileté? Si tel est le cas, vous voudrez peut-être avoir une file d'attente de producteur / consommateur - avoir un seul thread récupérant des éléments à écrire de la file d'attente et à les écrire, puis d'autres threads peuvent mettre librement des objets sur la file d'attente.

Êtes-vous sûr d'avoir un problème de performance cependant? 10 Mo est assez petit ces jours-ci ... sur mon netbook, il ne prend toujours qu'une seconde ou deux pour écrire 10 Mo (et non, ce n'est pas un lecteur d'état solide).


0 commentaires

0
votes

Utilisez un StringBuilder pour concaténer votre texte et ouvrir uniquement et écrire une fois dans le fichier.


2 commentaires

Un StringBuilder stockera cependant tout le fichier en mémoire.


10 Mo de mémoire !? C'est inouïe de! ;-)



0
votes

Dans les deux scénario 1 et 2, vous devez vous demander si un accès simultané au fichier est requis. Dans ce cas dans Scénario 2 Streamwriter n'est pas une option car elle n'est pas synchronisée. Dans le scénario 1, vous devez ouvrir chaque streamwriter de manière à ce qu'il obtienne un verrou exclusif sur le fichier.

Assumer un accès séquentiel, je n'irais jamais avec le scénario 2. Cela nécessite de passer autour de votre Streamwriter à chaque section du code qui en a besoin. Et qui est responsable de la fermeture de l'écrivain. Cela deviendra rapidement stimulable.

Scénario 1 a l'inconvénient que vous devez ouvrir un streamwriter partout où vous en avez besoin, ce qui devient également systématique. En outre, vous devez maintenant savoir dans chaque section de code l'emplacement du fichier.

J'irais pour un wrapper singleton autour du streamwriter afin que vous puissiez l'utiliser partout que vous aimez sans créer de nombreuses dépendances sur le streamwriter lui-même.


0 commentaires

0
votes

Il suffit de mélanger les deux approches ... Utilisez un tampon qui vous permet de stocker uniquement autant que vous le souhaitez en mémoire. Une fois dépassé cette taille, votre tampon sera écrit sur disque et nettoyé.


0 commentaires