0

J'essaie de lire à partir d'un fichier mappé en mémoire, mais l'accès au fichier prend beaucoup de temps. Je suis la cartographie de l'ensemble du fichier à mon programme, et l'accès initial à rapide, mais il commence à ralentir considérablementMemory Mapped FIle est lent

Le fichier est ~ 47 Go et j'ai 16 Go de RAM. J'utilise une application 64 bits sur Windows 7 en utilisant Visual Studios comme IDE. Voici l'extrait de mon code

hFile = CreateFile("Valid Path to file",    // name of the write 
         GENERIC_READ , // open for reading 
         0,      // do not share 
         NULL,     // default security 
         OPEN_EXISTING,    // existing file only 
         FILE_ATTRIBUTE_NORMAL, // normal file 
         NULL);     // no attr. template 

    if (hFile == INVALID_HANDLE_VALUE) 
    { 
     cout << "Unable to open vals" << endl; 
     exit(1); 
    } 

    hMapFile = CreateFileMapping(
           hFile,    
           NULL,      // default security 
           PAGE_READONLY,  // read/write access 
           0,       // maximum object size (high-order DWORD) 
           0,       // maximum object size (low-order DWORD) 
           NULL);      // name of mapping object 

    if (hMapFile == NULL) 
    { 
     cout<< "Error code " << GetLastError() << endl; 
     exit(1); 
    } 



    data = (float*) MapViewOfFile(
          hMapFile, 
          FILE_MAP_READ, 
          0, 
          0, 
          0); 

    if (data == NULL) 
    { 
     cout << "Error code " << GetLastError() << endl; 

     CloseHandle(hFile); 

     exit(1); 
    } 

Est-ce simplement parce que le fichier est si important que la permutation en continu des morceaux du fichier prend beaucoup de temps, ou est-il un autre paramètre que j'ai besoin d'un accès plus rapide?

EDIT: J'ai essayé d'utiliser lecture seule au lieu d'utiliser lire, écrire, exécuter comme vu ci-dessus, mais la vitesse est toujours lente. Je comprends les concepts de la cartographie de la mémoire et l'échange de l'espace de commutation, mais je pensais que je pouvais avoir fait quelque chose d'autre avec entravait la vitesse

+1

Je n'utiliserais définitivement pas 'PAGE_EXECUTE_READWRITE' ou' GENERIC_EXECUTE' pour un fichier de données. –

+2

Une fois que vous avez utilisé suffisamment de fichier pour remplir votre RAM disponible, l'accès à un nouveau bloc nécessite l'échange d'un autre bloc. Bien sûr, ça va ralentir. –

+0

Quel est votre modèle d'accès typique? Accédez-vous au fichier dans un ordre aléatoire ou séquentiel? Est-ce que vous touchez tout le fichier ou seulement des parties de celui-ci? Votre vue est en lecture seule, mais vous ouvrez tout le reste avec lecture/écriture et exécution (!). Ne demandez pas plus d'accès que nécessaire, car cela peut créer des contraintes qui ralentissent les choses. –

Répondre

1

Ceci est dû à la pagination. Qu'est-ce qui se passe, c'est que votre RAM ne peut contenir que 16 Go du fichier (en réalité, il est moins en raison d'autres programmes en cours d'exécution sur votre ordinateur, mais utilisons simplement cela pour plus de simplicité). Donc, si vous accédez à une partie du fichier de votre programme qui n'est pas en RAM (disons, une partie du fichier qui se trouve dans le segment de 20 Go), votre RAM doit communiquer avec le disque et transférer une toute nouvelle segment du fichier en RAM. Cela prend beaucoup de temps.

+0

Mais alors, comment les autres applications qui accèdent à des fichiers volumineux restent-elles le plus souvent réactives? Est-ce à travers le threading de sorte que chaque thread regarde différentes parties du fichier? –

+0

Les disques @ user2521432 sont optimisés pour l'accès série (même les disques SSD) et c'est le modèle d'accès typique, donc les choses sont rapides. Chaque fois que vous faites un accès aléatoire intense à un fichier, cela va être lent, peu importe si vous le lisez directement ou si vous laissez le système d'exploitation le faire via le mappage de la mémoire. –