Discussion :

[AsmCode]

Bonjour, je cherches la façon la plus rapide de lire tout les octets d'un fichier de plus de 50mb.

Jusqu'ici je lisais cela à coup de 1024 octets, mais quand j'ai un fichier d'environ 1gig, ça prend quand même 4-5 min à mon pc pour lire tout le fichier.

Voici le code que j'utilises en ce moment:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <cstdio>
#include <fstream>
#include <iostream>
#include <vector>
 
using namespace std;
 
int main()
{
 
	const unsigned long n = 1024;
 
	vector<char> Temp(n); 
 
	ifstream myFile ("X:\\fichier", ios::in | ios::binary);
 
	if (myFile.is_open())
	{
 
		do
		{		
 
			myFile.read (&Temp[0], n);
 
 
		} while(myFile.good());
 
		myFile.close();
 
		cin.get();
 
	}
 
	return 0;
}

[JolyLoic]

Si tu as besoin de la rapidité maximale, il te faut ici quitter le C++ standard et utiliser directement des fonctions spécifiques à ton OS.

[Raton]

En meme temps je vais peut etre dire une connerie... Mais 4-5 min pour charger 1Go... Ca me parait pas super long...

[sebA]

Salut

il me semble avoir lu ds la doc de $soft que la maniere la plus rapide c'est de lire un fichier par chunk de 64kB soit 65536 bytes

D'ailleurs j'ai lu et teste et effectivement c'est ca. Je sais pas si sur une autre plateform c'est la meme chose ....

Et si tu utilises la STL c'est transparent, la STL utilise en intern l'API de l'OS sur lequel tu es.


@+
Seb

[Aurelien.Regat-Barrel]

Moi aussi ça me parrait assez long. Augmente la taille de ton buffer, compile en release, ... Le but est de réduire le nombre de lectures. Là tu en fait 1 million. Multiplie la taille de ton buffer par 1024 et tu en fera plus que 1000... Le surcout C++ devrait alors devenir négligeable.
Si ça ne l'est pas, alors comme te l'a dit Loïc il faudra passer par les fonctions système.

[Rafy]

Tu te fais un benchmarck pour regarder suivant la taille de ton buffer, le temps que met le chargement, tu devrai avoir une sorte de parabole tournée vers le haut, alors tu regarde pour quelle taille de buffer tu as le temps de chargement mini...

C'est ce que j'avais fait avec les fonctions des windows WriteFile et ReadFile (j'avais trouvé un buffer de 2048 octets)

Moi aussi ça me parrait assez long. Augmente la taille de ton buffer, compile en release, ... Le but est de réduire le nombre de lectures. Là tu en fait 1 million. Multiplie la taille de ton buffer par 1024 et tu en fera plus que 1000... Le surcout C++ devrait alors devenir négligeable.

Il est vrai que le nombre d'appels sera diminué mais après c'est la fonction qui mettera du temps à s'executer car elle devra travailler sur un buffer trop grand....

[AsmCode]

Donc en résumé, il faudrait que je lise par bloc de 65536 octets tout en utilisant les API win32 ?

[Rafy]

Ben je pense que les fontions de windows sont pas mal et qu'il est facile de faire quelque chose de performant avec....

[Aurelien.Regat-Barrel]

Il est vrai que le nombre d'appels sera diminué mais après c'est la fonction qui mettera du temps à s'executer car elle devra travailler sur un buffer trop grand....

je comprends pas trop ce que tu veux dire. Si y'a 1Go de données à traiter, ben faut traiter 1Go de données. Avoir un grand buffer peut poser problème si la mémoire est saturée et que ça swappe. Mais 1Mo, de nos jours, ça me parrait pas énorme pour un usage ponctuel.

[Rafy]

Ce que je veux dire c'est que si on envoye un tout petit buffer à la fonction, alors il va falloir appeler plein de fois la fonction, c'est ça qui va nous ralentir, mais si au contraire on donne un buffer géant à la fonction, oui il faudra l'appeler moins de fois, mais c'est la fonction qui va peiner à traiter le gros buffer qu'on lui à donné, ça sera la fonction qui va nous limiter....
Ce que je voulais dire c'est qu'il faut lui envoyer un buffer pas trop grand pour que la fonction ne nous limite pas, et pas trop petit pour que ce ne soit pas le nombre d'apelle qui nous pénalise...

[la drogue c'est mal]

d'apres mes souvenirs des cours d'info de programmation systeme, quand tu fais une lecture de fichier, ifstream "bufferise" la lecture c'est a dire que c'est pas parce que tu demandes une lecture octet par octet que la methode va lire de cette facon.

Il va livrer l'info selon tes besoins mes l'acces disque n'est pas proportionné à la taille de ton buffer.

[philippe V]

tu peux utiliser la fonction bas niveau read() de io.h pour lire ton fichier mais le guin de temp sera minime

4 a 5 minute pour lire 1Gig ces rapide si tu travaille sur un Vic-20

[Aurelien.Regat-Barrel]

ifstream bufferise, et l'OS aussi derrière. Mais si tu te reposes trop sur ça, chaque lecture d'octet va être très couteuse car il faut faire un appel de fonction a chaque fois. Alors que si tu gères ton buffer, lire un octet est immédiat (adresse dans un tableau).

Pour l'histoire de la fonction qui peine avec un gros buffer, désolé mais je comprend pas pourquoi elle peine.

[Rafy]

Pour l'histoire de la fonction qui peine avec un gros buffer, désolé mais je comprend pas pourquoi elle peine.

Ben alors je comprend pas pourquoi on utilise pas alors des buffers aussi gros que le fichier que l'on veut lire ?
Dans ce cas si on veux lire 1 Go dans un fichier on peut alors donner la fonction un buffer de 1 Go ?
ça ne va pas être super lent ?

[Aurelien.Regat-Barrel]

Ce serait l'idéal. Mais on est limité par la taille de la RAM disponible, donc faut voir moins grand. Le truc est de trouver un bon compromis entre gain de performance mesurable et occupation mémoire. Il arrive un moment où augmenter la taille du buffer n'apporte plus grand chose, si ce n'est une consommation mémoire supérieure, qui peut donc être qualifiée d'inutile. Faut tester...

[zdra]

Ce serait l'idéal. Mais on est limité par la taille de la RAM disponible, donc faut voir moins grand. Le truc est de trouver un bon compromis entre gain de performance mesurable et occupation mémoire. Il arrive un moment où augmenter la taille du buffer n'apporte plus grand chose, si ce n'est une consommation mémoire supérieure, qui peut donc être qualifiée d'inutile. Faut tester...

Surtout si c'est pour que l'OS te swap ton buffer...

[Rafy]

Vous allez dire qu'il faut mais ceci fonctionne avec des fonctions qui sont d'ordre n ou inférieur.
Suivez mon résonnement :
Si on a une fonction d'ordre n² par exemple. Alors l'appel de la fonction pour un buffer de taille 2*d sera plus long que pour deux appels de la fonction pour un buffer de taille d....
C'est ça que je veux dire...
Suis-je dans le faux ?
Ou bien à coté de la plaque :
Ne ma laissez pas dans l'ignorance please...

[Aurelien.Regat-Barrel]

Je comprend l'idée, mais dans la pratique, ça n'a pas grand chose à voir. Faut distinguer la lecture des données de leur traitement. Si tu as une fonction en O², que tu dois appliquer sur l'ensemble du fichier. Quoique tu fasses, tu devras appliquer la fonction sur toutes les données du fichier, en tant que gros bloc contigue. Si tu morcelles ton traitement, tu n'auras pas le même résultat donné par la fonction.
Et lire des bloc de 1Mo ne t'empêche pas d'analyser ce gros bloc par petits morceaux de 1Ko.

[Rafy]

ok, compris.
Je m'incline et comprends....
C'est donc pareil pour la lecture et l'écriture.
L'acces se fait au fichier par l'intermédiaire d'un tampon pour ne pas avoir de grandes quantité de donnée stocké en mémoire (ce qui pourrait avoir des consequences sur les performances). Le travail effectué par la suite sur le tampon est libre, on peut travailler comme on veut sur les données...
Quoi qu'il arrive la lecture (et l'écriture je suppose), devront être fait sur l'ensemble du fichier, ne pas prendre une grande quantité de donnée n'est que reculer pour mieux sauter ....

Merci Aurelien