E / S de fichiers avec flux - meilleure taille de mémoire tampon
J'écris une petite bibliothèque d'E/S pour aider avec un plus grand projet (hobby). Une partie de cette bibliothèque exécute diverses fonctions sur un fichier, qui est lu/écrit via l'objet FileStream. A chaque StreamReader.Read(...) passe,
Je déclenche un événement qui sera utilisé dans l'application principale pour afficher des informations de progression. Le traitement qui se déroule dans la boucle est varié, mais ne prend pas trop de temps (il peut s'agir simplement d'une simple copie de fichier, ou peut impliquer un chiffrement ...).
Ma question principale est: Quelle est la meilleure taille de mémoire tampon à utiliser? En pensant aux dispositions de disque physique, je pourrais choisir 2k, ce qui couvrirait une taille de secteur de CD et est un multiple agréable 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 qu'avec les PC d'aujourd'hui, je pourrais opter pour une option plus gourmande en mémoire (quelques MiB, par exemple), mais j'augmente le temps entre les mises à jour de l'interface utilisateur et l'utilisateur perçoit une application moins réactive.
En passant, j'espère éventuellement fournir une interface similaire aux fichiers hébergés sur des serveurs FTP/HTTP (sur un réseau local/DSL rapide). Quelle serait la meilleure taille de mémoire tampon pour ceux-là (encore une fois, un compromis "meilleur cas" entre réactivité perçue et performances)?
Les fichiers sont déjà mis en mémoire tampon par le cache du système de fichiers. Il vous suffit de choisir une taille de tampon qui n'oblige pas FileStream à effectuer l'appel API Windows ReadFile () natif pour remplir le tampon trop souvent. Ne descendez pas en dessous d'un kilo-octet, plus de 16 Ko est un gaspillage de mémoire et hostile au processeur cache L1 (généralement 16 ou 32 Ko de données).
4 Ko 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 le temps qu'il faut pour lire un fichier mis en cache. Qui s'exécute à RAM, 5 gigaoctets/sec et plus si les données sont disponibles dans le cache. Ce sera dans le cache la deuxième fois que vous exécuterez votre test, et cela ne se produira pas dans un environnement de production trop souvent. Les E/S de fichiers sont complètement dominées par le lecteur de disque ou le NIC et sont glacialement lentes, la copie des données est des arachides. 4 KB fonctionnera bien.
Lorsque je traite des fichiers directement via un objet de flux, j'utilise généralement 4096 octets. Il semble être raisonnablement efficace dans 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. Il y a bien longtemps, j'ai vu plusieurs exemples utiliser cette taille, et elle est restée dans ma mémoire. Cela ne signifie pas pour autant que ce soit le meilleur.
"Ça dépend".
Vous devrez tester votre application avec différentes tailles de tampon pour déterminer ce qui est le mieux. Vous ne pouvez pas deviner à l'avance.