Question sur la mémoire et les fichiers

**Flynet** · 25/04/2010, 19h45

Bonjour,

J'ai depuis un certains une question que je n'arrive pas à résoudre. J'ai créer un programme de cryptage utilisant l'algorithme XOR. Ce dernier marche parfaitement, petit problème, il ne marche pas sur des fichier très gros de l'ordre du Go.
Un ami m'a expliqué que lorsqu'on fait "fopen" le fichier est chargé en mémoire.

Je me demandais donc s'il y avait une possibilité de gérer des fichiers de plusieurs Go. J'ai pensé à séparer le fichier en plusieurs parties mais ça ne résout pas le fait que le fichier est quand meme chargé en memoire.

Je sollicite donc votre aide

**ram-0000** · 25/04/2010, 21h10

Je ne sais pas s'il n'y a pas une limitation avec fopen sur la taille du fichier (dans le genre pas plus de 2 GO).

Autre piste, si tu es sous Microsoft, tu as MapViewOfFile() qui permet de mapper un fichier dans l'espace mémoire du process et qui est assez performant. Le fichier est mappé dans l'espace mémoire et les pages sont allouées par le système dès que tu accèdes aux différentes parties du fichier. Bien sûr, cela ne vaut que pour Microsoft, pour linux, regarde du côté de mmap()

**Flynet** · 26/04/2010, 20h49

Bonjour, je crois que la limitation pour fopen est celle de la memoire. Cependant j'avoue que j'ai quelques difficultées de comprehension. Tout d'abord que signifie "mapper" ? J'ai fait une recherche et la definition serait "faire correspondre un lien entre deux elements."

Dans le man du MapViewOfFile je ne comprends pas les parametres dwFileOffsetHigh et dwFileOffsetlow.

Je pense ne pas avoir le niveau nécessaire pour utiliser cette fonction.. Je n'ai jamais utiliser l'api win32... Y a t-il un tutoriel complet la dessus ?*

Edit : Pourquoi le descripteur du fichier dans mmap est de type int ? Ca ne devrait pas etre un pointeur vers le fichier ?

Est-ce que le fait de charger le fichier dans le processeur ne pose pas de probleme ? Celui-ci possedant moins de memoire deevrait etre vite saturé...

**Obsidian** · 27/04/2010, 00h25

Bonsoir,

« mapper », ou tout au moins « mappe » sont tout-à-fait français, proviennent de mappa : nappe, et consistent, d'une manière générale, en l'application d'une surface en deux dimensions (comme une feuille de papier) sur un support solide ou un volume en trois dimensions. La « 3D mappée », par exemple, consiste à coller une ou plusieurs textures sur un volume fait de polygones. Une mappemonde est une représentation de la carte du monde sur une sphère.

En programmation, « mapper un fichier » consiste à projeter son image intégrale en mémoire. Il n'y a plus de lecture explicite avec chargement d'un tronçon du fichier de taille fixe et à un emplacement donné, ni de fopen() ou fclose(). Tu passes le nom du fichier à projeter à l'appel système consacré, et celui-ci te retourne un pointeur sur le début du fichier.

Le système te fait donc croire qu'il est entièrement chargé en mémoire, ce qui n'est pas le cas. Les « pages » correspondant aux parties du fichier que tu lis sont chargées en temps réel au moment tu y accèdes en utilisant exactement les mêmes mécanismes que pour la mémoire swap. Ça peut marcher dans l'autre sens aussi : tu peux demander au système d'enregistrer automatiquement les modifs que tu fais. En fait, tu peux voir le swap comme un fichier mappé anonyme.

Les avantages sont évidents. Par contre, ça ne fonctionne que sur des fichiers, sur support à accès direct et de préférence en local. Tu auras donc toujours besoin de (f)open et (f)close pour lire des pipes, des lecteurs de bande, des terminaux, des ports série, etc.

**diogene** · 27/04/2010, 15h31

« mapper », ou tout au moins « mappe » sont tout-à-fait français,

Je crois qu'il s'agit plutôt d'anglicismes.

**Obsidian** · 27/04/2010, 20h57

Envoyé par diogene

Je crois qu'il s'agit plutôt d'anglicismes.

Curieusement, non !

Le Jargon Français signale qu'il en est fait état dès 1730 ici et ici. J'en ai aussi trouvé trace dans d'autres documents écrits sur lesquels je ne remets plus la main. « mappe » est dans le dictionnaire, et « mappa » est un mot latin.

Par contre, je suis contre la définition qui stipule « établir une correspondance entre deux choses distinctes ». C'est beaucoup trop imprécis. Un mappage est surtout une projection sur une structure existante, pour en épouser les caractéristiques.

**Flynet** · 27/04/2010, 21h24

Lol, je crois avoir compris a peu près. Et je pense que c'est cette fonction dont j'aurai besoin pour charger des fichiers sans limitation de taille.

Mais bien sur comme je l'ai dit, c'est un peu compliqué pour moi. Des notions comme offset me sont étrangères, je sais ce que c'est mais je ne l'ai jamais traité.

J'ai essayé de chercher le telechargement de la doc des api sur msdn mais a la place j'ai une doc sur visualstudio ... Ou alors est-ce celui là ?
Pourriez-vous m'aidez ? Si vous avez de tres bons tutos sur la api, je suis aussi prenant

**Obsidian** · 27/04/2010, 21h44

Envoyé par Flynet

Lol, je crois avoir compris a peu près. Et je pense que c'est cette fonction dont j'aurai besoin pour charger des fichiers sans limitation de taille.

Tu te trompes. Si le fichier est projeté intégralement en mémoire (même virtuellement), tu seras forcément limité par la taille de ton plan mémoire, et par ce qui y cohabite. En 32 bits, tu ne dépasseras pas trois ou quatre gigas.

Mais bien sur comme je l'ai dit, c'est un peu compliqué pour moi. Des notions comme offset me sont étrangères, je sais ce que c'est mais je ne l'ai jamais traité.

« Offset » signifie décalage, et désigne une adresse relative par rapport à un point de départ donné, que ce soit en mémoire ou dans un fichier. Par abus de langage, c'est souvent devenu synonyme d'adresse mémoire tout court, ou de position à l'intérieur d'un fichier.

Il faudrait surtout que tu nous dises à partir de quelle taille exactement ça commence à ne plus fonctionner. Bien souvent, les fichiers sont limités en taille à 2147483647 octets (la fameuse limite des deux gigas) parce que c'est la valeur maximum que l'on puisse représenter avec un entier 32 bits signé. Cette limitation peut ensuite être levée soit au niveau du système entier, soit à l'aide de fonctions homologues des fonctions ordinaires de gestion de fichiers, mais spécialement adaptée à la gestion des grandes tailles.

**Flynet** · 27/04/2010, 22h09

C'est vrai que si je charge le fichier intégralement il risque d'y avoir un bug. Mais tu as dit que seules les pages du fichier lu sont chargés. Je pense qu'il suffit de ne lire qu'une petite partie d'information sans saturer la memoire.

J'ai fait deux essais sur de gros fichiers avec mon programme. L'un de 300 mo environ et l'autre d'un 1 go plus. Bien sur le deuxieme n'a pas marché...

Sinon peux-tu m'orienté sur la voix à suivre ? ( je sais que ça se situe dans les api) mais je n'y connais absolument rien la dessus. Et j'avous etre pomé. Quel tuto est un bon début pour debuter dans les api ? ( qui explique vraiment bien )

**ironzorg** · 28/04/2010, 08h28

Je crois qu'il s'agit plutôt d'anglicismes.

A propos d'anglicismes, on ne dit pas 'crypter' mais chiffrer. Just sayin.

**Obsidian** · 28/04/2010, 11h10

Envoyé par Flynet

C'est vrai que si je charge le fichier intégralement il risque d'y avoir un bug. Mais tu as dit que seules les pages du fichier lu sont chargés. Je pense qu'il suffit de ne lire qu'une petite partie d'information sans saturer la memoire.

Ce n'est plus une question de saturation, à ce stade, mais d'adressage en mémoire. Avec 32 bits, on peut compter de 0 à 4264967295, uniquement, soit 4 gigas.

Oublie mmap() pour le moment, déclare un tampon de un méga-octet environ, et lis ton fichier par tranches. Si tu le fais avec les bonnes fonctions, il n'y a pas de raisons que cela plante. Surtout en dessous de 2 gigas.

J'ai fait deux essais sur de gros fichiers avec mon programme. L'un de 300 mo environ et l'autre d'un 1 go plus. Bien sur le deuxieme n'a pas marché...

Encore une fois, c'est trop vague. On aimerait savoir à quel endroit ça plante.

Sinon, peux-tu m'orienter sur la voie à suivre ? (je sais que ça se situe dans les A.P.I.) mais je n'y connais absolument rien là-dessus. Et j'avoue être paumé. Quel tuto est un bon début pour débuter dans les A.P.I. ? (qui explique vraiment bien)

Une A.P.I. est une Application Programming Interface. C'est la liste de toutes les fonctions, classes, procédures, etc. définies par une bibliothèque donnée et mises à ta disposition pour que tu puisses l'utiliser. Ce n'est pas une technologie particulière.

Poste ton code ici avec les balises [code] et [/code]. On tâchera de t'aider.

**pfeuh** · 28/04/2010, 12h49

Salut,

Envoyé par Flynet

Un ami m'a expliqué que lorsqu'on fait "fopen" le fichier est chargé en mémoire.

Quand on fait fopen, on crée simplement une structure en mémoire décrivant le fichier. c'est les instructions de la famille de fread qui chargent en mémoire. Rien ne t'empêche d'ouvrir un fichier en lecture, un deuxième en écriture et de coder/décoder à la volée par petits blocs de l'un vers l'autre. Pas besoin de tout charger en mémoire d'un coup. Si tu te penses obligé de charger en une seule fois ce genre de fichier, il faudrait peut-être revoir la conception de ton soft.

A+

Pfeuh

**Flynet** · 28/04/2010, 14h57

Lol merci pour la correction orthographique. Donc une api une liste des fonctions d'autres bibliotheques. Quelles sont les bibliotheques en jeu ?

Et donc si je comprends c'est fread qui charge le fichier en mémoire et non fopen ? la sa change tout. Je pourrais ouvrir un grand fichier et faire plusieurs fread et fwrite pour résoudre mon probleme.

Quant à mon code il marche bien, c'était juste un probleme de taille. Vu que je lisais le fichier en une seule fois.

**Obsidian** · 28/04/2010, 21h37

Envoyé par Flynet

Et donc si je comprends c'est fread qui charge le fichier en mémoire et non fopen ? la sa change tout. Je pourrais ouvrir un grand fichier et faire plusieurs fread et fwrite pour résoudre mon probleme.

C'est ce qu'il faut faire. D'habitude, on essaie de ne pas dépasser quelques kilo-octets quand on dimensionne le tampon qui va recevoir les lectures successives de ton fichier. Mais si tu es tout seul sur ta machine et que tu gères de gros fichiers, n'hésite pas à utiliser la mémoire à ta disposition (buffer de plusieurs mégas).

C'est vrai que les accès disques deviennent plus subtils sur les disques durs et avec les bêtes de courses qui équipent nos salons aujourd'hui. Par contre, essaie de faire la même chose en lisant un fichier sur disquette, si ta machine a toujours un lecteur floppy et, si possible, en désactivant le cache disque. Là, tu vas comprendre pourquoi il vaut mieux optimiser les accès fichiers. :-)

**Flynet** · 29/04/2010, 20h52

Malheuresement je n'en dispose pas sur mon portable. Mais de nos jours les disquettes sont devenues quasiment obsoletes non ?

Par contre en quoi la taille du buffer compte dans les lectures ? Il me semble que sur certains gestionnaires de copie, il est possible de régler la taille du buffer mais je n'en ai jamais su l'utilité...

**Obsidian** · 29/04/2010, 23h02

Envoyé par Flynet

Malheuresement je n'en dispose pas sur mon portable. Mais de nos jours les disquettes sont devenues quasiment obsoletes non ?

C'était simplement pour te montrer ce qu'est un accès disque avec un support suffisamment lent pour que ce soit perceptible. Quand j'étais jeune, j'avais un MO6 avec un lecteur de cassettes. Un quart d'heure pour charger MGT qui devait faire… quoi ? 40 kilo-octets peut-être :-) Pourtant ce n'est pas de la préhistoire, je l'ai eu en 1987.

Par contre en quoi la taille du buffer compte dans les lectures ? Il me semble que sur certains gestionnaires de copie, il est possible de régler la taille du buffer mais je n'en ai jamais su l'utilité...

Aujourd'hui, on exploite principalement un disque dur qui tourne en permanence, avec un système d'exploitation gérant un swap, un cache disque efficace qui délaie les enregistrements sur disque au bon moment de façon transparente pour l'utilisateur, etc. Toutes ces choses finissent par rendre les opérations d'entrées/sorties assez abstraites aux yeux de l'utilisateur alors qu'il devrait encore en tenir compte.

Les disques durs sont rapides mais ils restent environ mille fois plus lents que de l'accès à la mémoire vive. De toutes façons, c'est dans cette RAM que leurs informations sont chargées. D'autre part, l'ouverture d'un fichier et ses accès ont un coût ! Lire et enregistrer, c'est long et c'est fatiguant pour la mécanique.

Il est donc tout à ton avantage d'exploiter de travailler au maximum en mémoire, tant que tu le peux, et de tout enregistrer en une fois. Par contre, il est très déconseillé de conserver cette mémoire si ton programme est censé être résident sur ta machine et tourner en tâche de fond.

**Flynet** · 30/04/2010, 17h50

Bonjour,
merci de ta réponse, je comprends mieux à présent. Pour en revenir à mon programme. Je vois comment rajouter petits à petits les morceaux du fichier en ouvrant avec le parametre "ab"(ajout).

Mais pour la lecture en petites parties je ne vois pas. Ma fonction fread n'inclus pas de parametre pour choisir d'où l'on veut lire. A moins qu'il y est un curseur virtuel comme pour la fgets. Donc je pourrais utiliser fseek.

**Flynet** · 11/07/2010, 13h11

bonjour

j'ai essayé avec fread en ne lisant qu'un octet de données à la fois stocké dans un char. mais mon os ferme toujours le programme. N'y a t'il aucun moyen sur windows avc des fonctions basiques ?