Optimisation en accès lecture/écriture de fichier et divers

Version imprimable

26/01/2011, 21h19
Volgaan

Optimisation en accès lecture/écriture de fichier et divers

Bonsoir,

Avant tout, laissez-moi vous expliquer ce en quoi consiste mon humble projet afin de savoir ce que je recherche précisément. Dans le but de m'améliorer en C#, j'ai décidé il y a peu de temps de créer une application de découpage de fichiers (autrement dit, un "splitteur").

Il reçoit en entrée (via une GUI) le fichier à découper ainsi que la taille que devront avoir les paquets résultants. En sortie, on obtient un certain nombre de fichiers découpés à la bonne taille. Évidemment, il est possible de les réassembler à l'aide de cette même application.

Le format de fichier utilisé n'a rien de fantastique : des méta-données utiles au réassemblage suivies du contenu du fichier découpé; les méta-données contenant diverses informations telles que le hash MD5 du fichier d'origine (à des fins de contrôle d'intégrité), le nom du fichier original (stocké en Unicode) et d'autres informations du même acabit...

L'application fonctionne bien et fait son travail comme il se doit. Le problème est que j'ai maintenant envie de l'optimiser quelque peu.

Tout d'abord, l'écriture et la lecture des fichiers sont relativement lentes. Quelles sont les optimisations possibles à ce niveau ? Personnellement, j'ai utilisé des FileStream et des BinaryReader/BinaryWriter pour les manipuler. Est-ce que définir un buffer plus grand que celui par défaut (lors de l'initialisation) change radicalement la donne ?

J'ai aussi entendu parlé des fichiers mappés en mémoire. Peuvent-ils m'être utiles dans ce cas précis, sachant que les fichiers peuvent être petits comme immenses (plusieurs Go).

Une autre question est de savoir de quelle manière puis-je implémenter une fonction de création d'archive SFX (auto-extractible) ? J'imagine qu'il faille embarquer du code pré-compilé qui enroberait le binaire du fichier à extraire, si vous me comprenez...

Merci beaucoup pour votre aide que j'espère déjà être très enrichissante :ccool:

Volgaan
26/01/2011, 23h37
Graffito

Bonjour,

Pour optimiser, tu peux faire du MultiThread (c'est aujourd'hui une solution incontournable quand on veut tirer parti de la puissance apportée par les MultiCore).

On peut par exemple créer un thread pour le lecture et plusieurs threads (en fonction du nombre de core) pour le formatage et l'écriture.
26/01/2011, 23h56
tomlev

Citation:

Envoyé par Graffito

Pour optimiser, tu peux faire du MultiThread (c'est aujourd'hui une solution incontournable quand on veut tirer parti de la puissance apportée par les MultiCore).

C'est valable pour des traitement intensifs en calculs, pas pour des tâches d'IO comme c'est le cas ici... si tous les fichiers sont sur le même disque, le fait de faire plusieurs lectures/écritures à la fois va plus ralentir le traitement qu'autre chose
27/01/2011, 00h10
Graffito
Citation:

C'est valable pour des traitement intensifs en calculs, pas pour des tâches d'IO comme c'est le cas ici...

Probable, si on ne fait pratiquement que de l'IO :(.

Dans ce cas, éviter au maximum d'alterner lectures et écritures:
- lire le maximum en mémoire (disons 1Go) en faisant attention à ne pas allouer des milliers/millions de petits objets.
- traiter les formattages et écritures avant de continuer les lectures
27/01/2011, 18h10
Volgaan
Citation:
Envoyé par Graffito

Probable, si on ne fait pratiquement que de l'IO :(.

Dans ce cas, éviter au maximum d'alterner lectures et écritures:

lire le maximum en mémoire (disons 1Go) en faisant attention à ne pas allouer des milliers/millions de petits objets.
traiter les formattages et écritures avant de continuer les lectures
Donc je devrais éviter d'écrire directement chaque octet qui est lu et les stocker dans un buffer intermédiaire ?
27/01/2011, 18h18
tomlev

Citation:

Envoyé par Volgaan

Donc je devrais éviter d'écrire directement chaque octet qui est lu et les stocker dans un buffer intermédiaire ?

Tu veux dire qu'actuellement tu lis et écris les octets un par un ? Là c'est sûr que ce n'est pas très efficace... utilise plutôt un buffer. Commence par une taille de 4096 octets (taille d'un bloc en NTFS), et essaie éventuellement de faire varier pour trouver la taille optimale
27/01/2011, 18h24
Volgaan

Citation:

Envoyé par tomlev

Tu veux dire qu'actuellement tu lis et écris les octets un par un ? Là c'est sûr que ce n'est pas très efficace... utilise plutôt un buffer. Commence par une taille de 4096 octets (taille d'un bloc en NTFS), et essaie éventuellement de faire varier pour trouver la taille optimale

Euh... oui, je les lis et les écris un par un :pastaper:

Donc en gros, il me serait mieux de créer un buffer fixe de 4096 octets que je remplis entièrement avant de l'écrire dans le fichier ?

Est-ce que modifier la taille du buffer par défaut du FileStream est aussi efficace ? De même, est-ce qu'il serait plus optimisé de ne pas avoir à utiliser un FileStream à chaque fois, mais directement initialiser les BinaryReader/Writer sans ceux-ci ?
27/01/2011, 19h16
tomlev

Citation:

Envoyé par Volgaan

Donc en gros, il me serait mieux de créer un buffer fixe de 4096 octets que je remplis entièrement avant de l'écrire dans le fichier ?

Oui

Citation:

Envoyé par Volgaan

Est-ce que modifier la taille du buffer par défaut du FileStream est aussi efficace ?

Je ne pense pas que ça change grand chose, la taille par défaut est 4096

Citation:

Envoyé par Volgaan

De même, est-ce qu'il serait plus optimisé de ne pas avoir à utiliser un FileStream à chaque fois, mais directement initialiser les BinaryReader/Writer sans ceux-ci ?

Ben c'est pas possible, les constructeurs de BinaryReader/Writer prennent un Stream en paramètre...
Par contre tu n'as sans doute pas besoin du BinaryReader/Writer, tu peux manipuler le Stream directement (enfin ça dépend de ce que tu fais exactement, mais vu qu'on a pas vu ton code...)

Citation:

Envoyé par tomlev

Par contre tu n'as sans doute pas besoin du BinaryReader/Writer, tu peux manipuler le Stream directement (enfin ça dépend de ce que tu fais exactement, mais vu qu'on a pas vu ton code...)

Voilà comment je procède actuellement pour écrire dans les fichiers :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
int partCount = 1;
            fileHash = HashWithMD5(fileName);
 
            fsread = new FileStream(fileName, FileMode.Open, FileAccess.Read);
 
            try
            {
                fswrite = new FileStream(fileName + "." + convertToString(partCount) + ".nsp", FileMode.CreateNew);
            }
            catch (IOException ex)
            {
                MessageBox.Show(ex.Message, "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
                fsread.Close();
                watch.Stop();
                return;
            }
 
            br = new BinaryReader(fsread);
            bw = new BinaryWriter(fswrite);
 
            // Write meta-datas
            writeMetadatas(true);
 
            // Write files datas
            if (partSize <= fileSize)
            {
                for (long i = 0; i < fileSize; i++)
                {
                    if (i % (partSize - 576) == 0 && i != 0)
                    {
                        partCount++;
                        bw.Close();
                        fswrite.Close();
                        fswrite = new FileStream(fileName + "." + convertToString(partCount) + ".nsp", FileMode.CreateNew);
                        bw = new BinaryWriter(fswrite);
                        writeMetadatas(false);
                    }
 
                    bw.Write(br.ReadByte());
                }
            }
 
            bw.Close();
            br.Close();
            fsread.Close();
            fswrite.Close();

La valeur 576 que l'on retrouve correspond à la taille en octets des meta-données en début de fichier.

27/01/2011, 19h37
tomlev

OK... déjà, tu peux utiliser Stream.Read et Stream.Write à la place de BinaryReader.ReadByte et BinaryWriter.WriteByte. Est-ce que tu utilises le BinaryWriter pour écrire les métadonnées ?

Oui, je procède de la manière suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
private void writeMetadatas(bool isFirstPartFile)
        {
            bw.Write(Encoding.ASCII.GetBytes(fileFormat));
            bw.Write(Encoding.ASCII.GetBytes(fileVersion));
 
            // Write splitter name
            bw.Write(Encoding.ASCII.GetBytes(softName));
 
            for (int i = 0; i < 20 - softName.Length; i++)
            {
                bw.Write((byte)0);
            }
 
            if (isFirstPartFile)
            {
                // Write real file name
                bw.Write(Encoding.Unicode.GetBytes(safeFileName));
 
                for (int i = 0; i < 510 - safeFileName.Length * 2; i++)
                {
                    bw.Write((byte)0);
                }
 
                // Write MD5 hash of file
                for (int i = 0; i < fileHash.Length; i++)
                {
                    bw.Write(fileHash[i]);
                }
 
                // Write number of parts
                bw.Write((Int16)(fileSize / partSize + ((fileSize % partSize != 0) ? 1 : 0)));
 
                // Padding bytes
                for (int i = 0; i < 7; i++)
                {
                    bw.Write((byte)0);
                }
            }
            else
            {
                for (int i = 0; i < 551; i++)
                {
                    bw.Write((byte)0);
                }
            }
        }

La principale raison d'utilisation de BinaryReader/Writer était qu'il m'était indispensable d'écrire les données parfaitement dans les fichiers, à l'octet près, sans aucune interprétation derrière (comme avec StreamReader/Writer, il me semble).

Pour les méta-données, le nom original du fichier doit être préservé dans son entièreté : accents, caractères spéciaux, etc.

Comme il est possible sous Windows d'enregistrer un nom de fichier ayant 255 caractères (UTF-16) maximum, j'en réserve 510 pour l'écrire au format Unicode.

27/01/2011, 21h39
tomlev

OK... Donc en fait tu n'as besoin du BinaryWriter que dans writeMetadatas.

Par contre, tu ne peux pas le fermer dans writeMetadatas, sinon ça ferme le stream sous-jacent...
27/01/2011, 22h00
Volgaan

Citation:

Envoyé par tomlev

OK... Donc en fait tu n'as besoin du BinaryWriter que dans writeMetadatas.

Par contre, tu ne peux pas le fermer dans writeMetadatas, sinon ça ferme le stream sous-jacent...

D'accord, merci pour tous tes conseils.

J'ai déjà implémenté le cache : avec de petits fichiers, ça va un peu plus rapidement, mais avec des gros (700 Mo), le gain de vitesse n'est pas perceptible pour ne pas dire inexistant, je l'avoue. Pour mesurer le temps précisément, j'utilise l'objet StopWatch.

J'ai essayé des caches d'une taille de 4'096, 16'384, 65'536 et 1'048'576 octets. Quasiment pas de différence dans le temps d'exécution...

Je vais essayer de n'utiliser que le FileStream là où je peux. La seule chose qui me gêne avec celui-ci, c'est qu'il ne peut pas lire de tableaux de bytes en écriture (le buffer que je lui envoie). Pas très grave, me dira-t-on, il me suffit de le faire manuellement avec une boucle en l'envoyant byte par byte.
27/01/2011, 22h07
tomlev

Citation:

Envoyé par Volgaan

La seule chose qui me gêne avec celui-ci, c'est qu'il ne peut pas lire de tableaux de bytes en écriture (le buffer que je lui envoie). Pas très grave, me dira-t-on, il me suffit de le faire manuellement avec une boucle en l'envoyant byte par byte.

Euh... je vois pas ce que tu veux dire. Tu n'as jamais besoin de travailler octet par octet, que ce soit en lecture ou en écriture. Utilise simplement les méthode Read et Write...
28/01/2011, 16h36
Volgaan

Citation:

Envoyé par tomlev

Euh... je vois pas ce que tu veux dire. Tu n'as jamais besoin de travailler octet par octet, que ce soit en lecture ou en écriture. Utilise simplement les méthode Read et Write...

Oui, désolé, j'avais fait un prototype "vite fait, mal fait" afin de tester le buffer... en utilisant encore les ReadByte et WriteByte :aie:

Maintenant que j'ai repris le code en utilisant les fonctions que tu m'as conseillées, c'est beaucoup plus rapide ! Avec 1 Mo de cache, couper un fichier de 700 Mo prend quatre fois moins de temps ! Ça décoiffe du tonnerre.

Maintenant que j'ai procédé à cette grand optimisation, y aurait-il autre chose que je puisse faire encore ?

De même, personne n'a encore répondu à ma question quant à savoir comment faire un système de création d'archives autoextractibles (SFX). Si quelqu'un est connaisseur, qu'il me fasse signe !
31/01/2011, 16h05
CIFQ_Drew

Citation:

Envoyé par Volgaan

De même, personne n'a encore répondu à ma question quant à savoir comment faire un système de création d'archives autoextractibles (SFX). Si quelqu'un est connaisseur, qu'il me fasse signe !

Une archives auto-extractibles est un exécutable : il y a la partie logique d'extraction ainsi que les données à l'intérieur.

Je vois deux composantes :

1. Une application de compression d'archives (avec l'option d'archivage auto-extractible) ;
2. Un application qui correspond à la logique de décompression : cette application peut recevoir un fichier .volgaan (fichier compresser) dont elle copie le contenue, disons, dans ses settings ;

Pour ma part, le deuxième point me semble être le défi, car on ne veut surtout pas passer par la compilation à chaque fois qu'on archive.

Sur ce, bonne chance.
28/02/2011, 22h10
Volgaan

Citation:

Envoyé par CIFQ_Drew

Une archives auto-extractibles est un exécutable : il y a la partie logique d'extraction ainsi que les données à l'intérieur.

Je vois deux composantes :

1. Une application de compression d'archives (avec l'option d'archivage auto-extractible) ;
2. Un application qui correspond à la logique de décompression : cette application peut recevoir un fichier .volgaan (fichier compresser) dont elle copie le contenue, disons, dans ses settings ;

Pour ma part, le deuxième point me semble être le défi, car on ne veut surtout pas passer par la compilation à chaque fois qu'on archive.

Sur ce, bonne chance.

Effectivement, c'est un défi, mais il est intéressant.

Je vais déjà utiliser un BackGrounderWorker afin que l'interface ne soit pas figée durant le traitement puis m'y attèlerais.