Comment écrivez-vous la fin d'un fichier ouvert avec FILE_FLAG_NO_BUFFERING?

Question

J'utilise VB6 et l'API Win32 pour écrire des données dans un fichier. Cette fonctionnalité est destinée à l'exportation de données. Les performances d'écriture sur le disque sont donc le facteur clé de mes considérations. En tant que tel, j'utilise les options FILE_FLAG_NO_BUFFERING et FILE_FLAG_WRITE_THROUGH lors de l'ouverture du fichier avec un appel à CreateFile .

FILE_FLAG_NO_BUFFERING nécessite que j'utilise mon propre tampon et écrive des données dans le fichier par multiples de la taille de secteur du disque. Ce n'est pas un problème en général, à part la dernière partie des données, qui pas un multiple exact de la taille du secteur n'inclura le caractère zéro dans le fichier, comment définir la taille du fichier une fois le dernier bloc écrit pour ne pas inclure ces caractères zéro?

Je peux utiliser SetEndOfFile , mais cela nécessite de fermer le fichier et de le rouvrir sans utiliser FILE_FLAG_NO_BUFFERING . J'ai vu quelqu'un parler de NtSetInformationFile , mais je ne trouve pas comment l'utiliser et le déclarer dans VB6. SetFileInformationByHandle peut faire exactement ce que je veux, mais il n'est disponible que sous Windows Vista, mon application doit être compatible avec les versions précédentes de Windows.

Answer 1

Je ne suis pas sûr, mais êtes-vous sûr que les paramètres FILE_FLAG_NO_BUFFERING et FILE_FLAG_WRITE_THROUGH vous offrent des performances maximales?

Vos données entreront certainement sur le disque le plus tôt possible, mais ce genre de choses n’aide en réalité pas les performances - cela améliore simplement la fiabilité des éléments tels que les fichiers journaux dans lesquels vous souhaitez être le plus complet possible. le cas d'un accident.

Pour une routine d’exportation de données telle que celle que vous décrivez, le fait de permettre au système d’exploitation de mettre en mémoire tampon vos données entraînera probablement de meilleures performances. En effet, les écritures seront planifiées en fonction de l’activité des autres disques, au lieu d’obliger le disque à revenir en arrière. déposer chaque écriture.

Pourquoi ne pas analyser votre code sans ces options? Laissez la logique de remplissage sur 0 octet pour en faire un test correct.

S'il s'avère que le saut de ces options est plus rapide, vous pouvez supprimer la logique de remplissage 0. Votre problème de taille de fichier se résout tout seul.

Answer 2

Je crois que SetEndOfFile est le seul moyen.

Et je suis d'accord avec Mike G. sur le fait que vous devriez associer votre code avec et sans FILE_FLAG_NO_BUFFERING. La mise en mémoire tampon de fichiers Windows sur les systèmes d’exploitation modernes est très efficace.

Answer 3

Eh bien, je suis émerveillé! L'utilisation de la mise en mémoire tampon Windows au lieu de tout faire moi-même est BEAUCOUP plus rapide. J'ai écrit un fichier de 1 Go à tester, en utilisant mon propre tampon et les options FILE_FLAG_NO_BUFFERING et FILE_FLAG_WRITE_THROUGH ont pris en moyenne 21,146 secondes, sans ces paramètres et à l'aide du tampon Windows. le temps moyen est tombé à 13,53 secondes, soit 30% plus vite!

Remarque personnelle: inutile de réinventer la roue. ; -)

Merci à Mike G pour votre réponse rapide et précise. Et merci également à vous, gabr , inutile de vous soucier de SetEndOfFile du tout.

Answer 4

Pour un fichier de 1 Go, la mise en mémoire tampon de Windows sera probablement plus rapide, en particulier. si vous faites beaucoup de petits IO. Si vous traitez avec des fichiers beaucoup plus volumineux que la RAM disponible et que vous effectuez des E / S de gros blocs, les indicateurs que vous définissez produiront doivent produire un meilleur débit (jusqu'à 3 fois plus rapide pour les E / S de gros blocs fortement threadées et / ou aléatoires).