E/S de fichiers avec flux - meilleure taille de mémoire tampon

Question

Je suis en train d'écrire une petite bibliothèque d'E/S pour vous aider dans un plus grand projet (passe-temps). Une partie de cette bibliothèque exécute diverses fonctions sur un fichier, qui est lu/écrit via l'objet FileStream. Sur chaque passe StreamReader.Read(...),

Je déclenche un événement qui sera utilisé dans l'application principale pour afficher les informations de progression. Le traitement qui se passe dans la boucle est vaired, mais ne prend pas trop de temps (il peut s'agir d'une simple copie de fichier, par exemple, ou peut impliquer un cryptage ...).

Ma question principale est: Quelle est la meilleure taille de mémoire tampon à utiliser? En pensant aux mises en page de disques physiques, je pourrais choisir 2k, ce qui couvrirait une taille de secteur de CD et est un bon multiple d'un secteur de disque dur de 512 octets. Plus haut dans l'arbre d'abstraction, vous pouvez opter pour un tampon plus grand qui pourrait lire un cluster FAT entier à la fois. Je me rends compte avec les PC d'aujourd'hui, je pourrais aller pour une option plus affamée de mémoire (un couple de MiB, par exemple), mais ensuite j'augmente le temps entre les mises à jour et l'utilisateur perçoit une application moins réactive. En passant, j'espère pouvoir fournir une interface similaire aux fichiers hébergés sur des serveurs FTP/HTTP (sur un réseau local/DSL fastish). Quelle serait la meilleure taille de mémoire tampon pour ceux-ci (encore une fois, un compromis «meilleur cas» entre la réactivité perçue et la performance)?

Answer 1

Les fichiers sont déjà mis en mémoire tampon par le cache du système de fichiers. Vous avez juste besoin de choisir une taille de buffer qui ne force pas FileStream à faire l'appel de Windows ReadFile() API natif pour remplir le buffer trop souvent. Ne pas aller en dessous d'un kilo-octet, plus de 16 Ko est un gaspillage de mémoire et hostile à la L1 cache du CPU (généralement 16 ou 32   Ko de données). KB est un choix traditionnel, même si cela ne couvrira exactement une page de mémoire virtuelle que par accident. Il est difficile de profiler; vous finirez par mesurer combien de temps il faut pour lire un fichier mis en cache. Ce qui fonctionne à des vitesses de RAM, 5 gigaoctets/s et plus si les données sont disponibles dans le cache. Il sera dans le cache la deuxième fois que vous exécuterez votre test, et cela n'arrivera pas trop souvent dans un environnement de production. Fichier I/O est complètement dominé par le lecteur de disque ou le NIC et est glacial lent, la copie des données est des cacahuètes. 4   KB fonctionnera bien.

Answer 2

Lorsque je traite des fichiers directement via un objet de flux, j'utilise généralement 4096 octets. Il semble raisonnablement efficace sur plusieurs zones d'E/S (système de fichiers local, LAN/SMB, flux réseau, etc.), mais je ne l'ai pas profilé ou quoi que ce soit. Quand j'ai vu plusieurs exemples utiliser cette taille, et il est resté dans ma mémoire. Cela ne veut pas dire que c'est le meilleur.

Answer 3

"Cela dépend".

Vous devrez tester votre application avec différentes tailles de mémoire tampon pour déterminer le meilleur résultat. Vous ne pouvez pas deviner à l'avance.