Temps de lecture disque

Version imprimable

15/09/2006, 11h17
Mucho

Temps de lecture disque

Bonjour,

j'ai un fichier composé de n groupe d'octets de tailles variables.

sous windowsXP SP2
je lis ce fichier à l'aide de n appels à la fonction fread.

lors de la première lecture du fichier le temps de lecture est T1

lors de la deuxième lecture et des lectures suivante le temps est environ entre T1/2 et T1/4 (dépends de la machine)

lorsque je ferme l'application et que je la relance les temps sont toujours entre T1/2 et T1/4.

Si je ferme la session les temps sont toujours courts.

Si je redémarre la machine (reboot) le temps est à nouveau T1 pour la première lecture.

Quelqu'un pourrait-il m'expliquer d'où vient ce phénomène ou où trouver des informations sur la lecture des fichiers avec windows qui pourraient expliquer ces temps.

D'avance merci, parce que là :marteau:
15/09/2006, 11h23
Médinoc

Ben... Les fichiers sont mis en cache, tout simplement...
Les Windows 9x accordaient 50% de la mémoire au "cache système" ce qui est un terme pour le cache (logiciel) supérieur des accès au disque dur (par opposition au "cache disque", qui est réservé au contrôleur de disque)

Je ne sais pas où trouver des infos détaillées, mais j'ai bossé pour un thésard qui travaillait justement sur les temps d'accès...
15/09/2006, 14h12
Mucho

Citation:

Envoyé par Médinoc

Ben... Les fichiers sont mis en cache,

Effectivement je me doute bien qu'il y a un cache

Citation:

Envoyé par Médinoc

tout simplement...

Par contre, je me demande bien comment est géré ce cache et ce qu'il contient, et ça ne me parait pas très simple :/

En effet, fread va lire les données sur le disque dur lors de tous les appels, il doit donc y avoir, je pense, une sorte "d'index des fichiers lus" en cache mais je ne sais pas du tout où trouver d'infos. :/
15/09/2006, 14h16
Eusebe

Il y a aussi un cache avec le disque dur.
Mais je ne sais pas comment ils sont gérés (ni le cache de l'OS ni le cache "physique").
15/09/2006, 14h48
Mucho

Voui,
et est-il possible de "préchargé" un fichier en cache avant de le lire ?
15/09/2006, 14h49
Ti-R

Non, mais tu peux le lire... :mrgreen: ce qui va le "précharger" :mouarf:
15/09/2006, 15h01
Médinoc

Quand tu commences la lecture du fichier, Windows va précharger le reste.

Avec les fonctions de l'API Win32 (comme CreateFile()), tu peux même optimiser en disant de quelle façon tu comptes accéder au fichier (avec FILE_FLAG_SEQUENTIAL_SCAN et FILE_FLAG_RANDOM_ACCESS)
15/09/2006, 15h08
mat.M

oui encore une fois il est souhaitable d'utiliser des API spécifiques comme CreateFile dont parle Medinoc plutot que fread du C ;)
15/09/2006, 15h27
Mucho

Hum...mais coté portabilité :/

donc mieux vaut faire un chargement spécifique à chaque platforme ?

Citation:

Envoyé par Médinoc

Quand tu commences la lecture du fichier, Windows va précharger le reste.

Peux-tu me préciser ce que tu entends par "commencer" la lecture et précharger le reste.

Je ne sais pas s'il suffit d'ouvrir le fichier ou s'il faut lire le premier octet (ou carrément le premier secteur). Toujours est-il que Windows chargera les secteurs suivants en avance, avant que tu ne les lises.

Bien entendu, c'est supposé plus performant en mode séquentiel...

PS: Tu as aussi des extensions non-standard à fopen(), qui permettent de spécifier cela:
http://msdn.microsoft.com/library/de...c_._wfopen.asp
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #ifdef WIN32 #define _CRT_SECURE_NO_DEPRECATE #define FOPEN_SEQ "S" #define FOPEN_RAND "R" #else #define FOPEN_SEQ #define FOPEN_RAND #endif #include <stdio.h> //... { //... FILE* pt_fich = fopen( nomFich, //Nom du fichier "r" FOPEN_SEQ //Juste un espace entre les deux, le compilo concatène ); //... }

15/09/2006, 22h33
vdumont

Pourquoi ne pas simplement utiliser ifstream?
15/09/2006, 22h41
Médinoc

Parce que les streams n'ont aucun moyen, standard ou non, de spécifier des flags d'optimisation du préchargement.
15/09/2006, 22h44
vdumont

Ah j'avais pas lu le post sur les flags ;)
18/09/2006, 09h23
Mucho

Citation:

Envoyé par Médinoc

Je ne sais pas s'il suffit d'ouvrir le fichier ou s'il faut lire le premier octet (ou carrément le premier secteur). Toujours est-il que Windows chargera les secteurs suivants en avance, avant que tu ne les lises.

Je vais essayé puisque sur un fichier de quelques centaines de Mo, je ne comprends pas vraiment ce qu'il charge lorsqu'on lit les premiers octets.

En ce qui concerne les options "Random" et "Sequential" mes essais n'ont pas été très concluant pour le moment.

Sinon pour ifstream, c'était du code C à la base d'où le fread, mais effectivement je ne sais pas non plus gérer le cache grâce aux fstreams.
18/09/2006, 09h38
Médinoc

Au fait: Fais gaffe si tu as un antivirus actif, ça peut fausser, surtout pour les fichiers compressés (Notamment, n'ouvres pas un tar.gz de 800Mo avec VScan qui tourne, mon 2600+ met un quart d'heure...).
18/09/2006, 14h39
loufoque

En portable, y'a ça qui pourrait peut-être t'intéresser :
http://ice.prohosting.com/newfunk/bo...pped_file.html
18/09/2006, 18h05
Mucho

Effectivement ca m'intéresse :D
je vais essayé de voir ce que je peux faire

Sinon en ce qui concerne fread, je suis encore plus perdu qu'avant :
J'ai obtenu de très bon résultat en lecture sequentiel, mais je ne les comprend pas.

J'ai lu un fichier (que j'estime "mis en cache" donc normalement rapide)
en N secondes.

J'ai redémarrer ma machine afin de vérifier:
la lecture prend toujours N secondes :D

En lisant un fichier similaire ailleurs sur le disque N secondes. :D

En lisant un autre fichier similaire ailleurs sur le disque environ 3*N secondes 8O :?
pour la première lecture, N secondes ensuite.

Je ne comprend pas vraiment ces résultats :
- est ce que ca pourrait être des informations de style "cache disque" stockées sur le disque ? ( ca me parait un peu tordu )
- est ce que ca pourrait être le fait qu'un fichier soit fragmenté ? (mais alors pourquoi juste la première lecture est lente ?)

BTW : j'avais oublié de préciser j'utilise une machine windows qui lit un disque au format NTFS
18/09/2006, 18h16
Ti-R

Citation:

Envoyé par Médinoc

Au fait: Fais gaffe si tu as un antivirus actif, ça peut fausser, surtout pour les fichiers compressés (Notamment, n'ouvres pas un tar.gz de 800Mo avec VScan qui tourne, mon 2600+ met un quart d'heure...).

Comme Médinoc, je penche plus pour un problème de scan antivirus ou autres logiciels dans le même genre.

Car déjà faire un cache sur un fichier de + de 100 mo... j'ai un très gros doute la !
Cache disque dur de 16 mo maxi, et monter en mémoire ensuite des fichiers de 100 Mo j’ai de gros doutes la aussi.

Et l'antivirus peut scanner le fichier la première fois, stocker des informations dessus, comme quoi il n’est pas infecté par un malware. Et pour les n fois suivante, il peut vérifier, via un md5 ou en vérifiant la taille du fichier, sa date de création ou autres, et ne pas rééxecuter son scan une seconde fois.
18/09/2006, 18h41
homeostasie

Citation:

Euseube:
Il y a aussi un cache avec le disque dur.

Je ne savais pas cela mais il fonctionne comment en fait? Ne serais pas plutot le cache L2?
Le processeur le gère de quelle manière? Seulement pour des fichiers spécifiques?
18/09/2006, 19h17
loufoque

Citation:

Je ne savais pas cela mais il fonctionne comment en fait? Ne serais pas plutot le cache L2?
Le processeur le gère de quelle manière? Seulement pour des fichiers spécifiques?

Non, il parle d'un cache interne au disque dur.
La gestion de ce cache dépend du disque dur utilisé.
18/09/2006, 23h28
koala01

Salut,

Juste une petite intervention pour signaler que la vitesse du plateau étant constante quel que soit la position de la tete de lecture, le défilement des informations est plus rapide sur le bord exterieur du plateau que sur son bord intérieur (pres de l'axe)

Pour éviter d'avoir des blocs de données *trop* éparpillés (les fameux 512 octets ;)) le rayon du plateau est divisé en un certain nombres de zone contenant chacune un nombre différents de blocs...

Quand le plateau fait un tour entier, la tete de lecture passe peut etre sur 16 ou 42fois plus de blocs en bordure de plateau que pres du centre (chiffres donnés strictement au hasard, c'est parfois moins, parfois plus ;))

Il s'en suit qu'un fichier se trouvant en bordure du plateau sera susceptible d'etre lu beaucoup plus rapidement que le fichier de meme taille se trouvant pres du centre...

Cela peut expliquer la différence de temps;)

***Ce raisonnement n'est valable que pour les disques durs, la vitesse de rotation des CD-ROM/DVD-ROM étant variable pour lire en permanence le meme nombre de blocs sur un temps donné ;)***