IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Choix de containers et temps de calculs


Sujet :

C++

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 53
    Par défaut Choix de containers et temps de calculs
    Bonsoir à tous.
    Je poste ce sujet car les temps sont difficiles.
    Voici le problème : J'ai un fichier de 16000 lignes, chaque ligne étant de la forme suivante => "111:BBE|24". Le programme lit le fichier et est censé enregistré dans un container de type map les informations de ce fichier, la clé étant "111:BBE" de type string et la valeur étant un entier (ici 24). Le souci c'est que, pour lire et enregistrer mes 16000 lignes, le programme met environ 20 ms sur mon ordinateur. Sachant que les autres taches (qui consiste à lire des fichiers aussi long, à les interpréter et effectuer des calculs de toutes sortes) mettent 10 ms. En tout, ces 16000 lignes représentent 66% de temps d'utilisation, et c'est 66% inutiles. Je veux bien 1ms mais pas 20 !!!

    Ma question est ainsi la suivante : Comment faire pour éviter autant de temps perdu ???!!!!

    J'ai essayé de séparer les deux données (clé et valeur) dans deux vectors, c'est légèrement mieux mais insuffisant.
    J'ai essayé d'intégrer les 16000 lignes dans le programme directement, je vous parle pas de l'horreur (je le savais dès le départ, je voulais savoir ce que ca donnais !! )

    En gros je suis un peu perdu... un coup de main !!
    Merci d'avance.

    Voici le code:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    map<string,int>PH4_pos;
    string str;
    char[512] buffer;
    FILE *fp = fopen("fichier","r");
     while (!feof(fp))
        {
           fgets(buffer,511,fp);str=buffer;
    PH4_pos.insert(pair<string, int>(str.substr(0,8),atoi(str.substr(9))));
        }
     
        fclose(fp);
    Je sais pour les puristes,c'est moche désolé !!!
    Merci encore !!

  2. #2
    screetch
    Invité(e)
    Par défaut
    ca fait beaucoup d'allocations memoires ca
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     while (!feof(fp))
        {
            fgets(buffer,511,fp);
            str=buffer; // 1 allocation
            PH4_pos.insert( // 1 allocation pour le noeud dans l'arbre
                     pair<string, int>( // 1 copie de la clé dans l'arbre
                          str.substr(0,8), // 1 allocation dans substr
                          atoi(str.substr(9)))); // 1 allocation dans substr
        }
    essaye:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    map<string,int>PH4_pos;
    char[512] buffer;
    char[512] key;
    int value;
    FILE *fp = fopen("fichier","r");
    while (!feof(fp))
    {
        fgets(buffer,511,fp);
        sscanf(buffer, "%s|%d", key, &value);
        PH4_pos.insert(std::make_pair(key, value));
    }
    qui devrait largement diminuer le nombre d'allocations (3 je crois, peut etre 2).
    apres, ca reste des std::string et des std::map

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 53
    Par défaut
    Merci pour ta réponse, screetch.
    Je viens d'essayer ta méthode, et hélàs ... c'est pire !!!!
    J'obtiens 26 ms par test au lieu des 20 auparavant !!

    Après je vois qu'un seul moyen brutal de faire ca, c'est de créer deux tableaux de taille fixe et d'enregistrer les données dedans ... pas de vérification, pas d'allocation en plus, rien que le strict minimum ... mais bon, c'est moyen ...

  4. #4
    Membre Expert
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Par défaut
    Utilise spirit.

  5. #5
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Salut,
    Quand tu étais sur std::vector, as-tu utiliser std::vector::reserve au départ ?
    Comme dit screetch, tu devrais chercher à minimiser (supprimer) les allocations dans ta boucle.
    En particulier, pour le coup, remplace std::string soit par un std(ou boost)::array<char,5>
    J'ai fais quelques tests à l'arrache avec visual et gcc en mode release sur un fichier avec 640 000 entrées :
    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
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    #include <iostream>
    #include <fstream>
    #include <map>
    #include <string>
    #include <iomanip>
    #include <vector>
    #include <cstdlib>
    #include <boost\timer.hpp>
    #include <boost\array.hpp>
    #include <algorithm>
    #include <utility>
     
    static std::string const directory = "D:\\Informatique\\cpp\\projets\\Tests\\TestCpp\\TestCpp\\";
    static const int nbr_element = 640000;
     
    typedef boost::array<char,8> fixed_size_string_t;
    typedef std::pair<fixed_size_string_t,int> element_t;
     
    inline int compare(char const *first, char const *second, int count)
    {
       for (; 0 < count; --count, ++first, ++second)
    	   if (*first!=*second)
    		   return (*first < *second ? -1 : +1);
       return (0);
    }
     
    inline bool operator<(element_t const& lhs_, element_t const & rhs_)
     
    {
       return compare(lhs_.first.begin(),rhs_.first.begin(),8)<0 ?true:false;
    }
     
     
     
    void read_1(FILE *pf_)
    {
       std::map<std::string,int>PH4_pos;
       std::string str;
       char buffer[512];
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);str=buffer;
          PH4_pos.insert(std::pair<std::string, int>(str.substr(0,8),atoi(str.substr(9).c_str())));
       }
    }
     
    int read_2(FILE *pf_)
    {
       std::map<std::string,int>PH4_pos;
       char buffer[512];
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          PH4_pos.insert(std::pair<std::string, int>(std::string(buffer,buffer+8),atoi(buffer+8)));
       }
       return PH4_pos.size();
    }
     
    void read_3(FILE *pf_)
    {
       std::vector<fixed_size_string_t> vect_cles;
       std::vector<int>vect_valeurs;
       fixed_size_string_t cles;
       char buffer[512];
       vect_cles.reserve(nbr_element);
       vect_valeurs.reserve(nbr_element);
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          std::copy(cles.begin(),cles.end(),buffer);
          vect_cles.push_back(cles);
          vect_valeurs.push_back(atoi(buffer+8));
       }
    }
     
     
    void read_3_bis(FILE *pf_)
    {
       std::vector<fixed_size_string_t> vect_cles;
       std::vector<int> vect_valeurs;
       char buffer[512];
       vect_cles.resize(nbr_element);
       vect_valeurs.resize(nbr_element);
       std::vector<fixed_size_string_t>::iterator it_cles = vect_cles.begin();
       std::vector<int>::iterator it_valeurs = vect_valeurs.begin();
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          std::copy(it_cles->begin(),it_cles->end(),buffer);
          *it_valeurs = (atoi(buffer+8));
       }
    }
     
     
    void read_4(FILE *pf_)
    {
       std::vector<element_t> vecteur;
       fixed_size_string_t cles;
       char buffer[512];
       vecteur.reserve(nbr_element);
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          std::copy(cles.begin(),cles.end(),buffer);
          vecteur.push_back(element_t(cles,atoi(buffer+8)));
       }
    }
     
    void read_4_bis(FILE *pf_)
    {
       std::vector<element_t> vecteur;
       char buffer[512];
       vecteur.resize(nbr_element);
       std::vector<element_t>::iterator it=vecteur.begin();
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          std::copy(it->first.begin(),it->first.end(),buffer);
          it->second = atoi(buffer+8);
       }
    }
     
     
    void read_5(FILE *pf_)
    {
       typedef boost::array<char,8> fixed_size_string_t;
       typedef std::pair<fixed_size_string_t,int> element_t;
       std::vector<element_t> vecteur;
       fixed_size_string_t cles;
       char buffer[512];
       vecteur.reserve(nbr_element);
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          std::copy(cles.begin(),cles.end(),buffer);
          vecteur.push_back(element_t(cles,atoi(buffer+8)));
       }
     
       std::stable_sort(vecteur.begin(),vecteur.end());
    }
     
    void read_5_bis(FILE *pf_)
    {
       std::vector<element_t> vecteur;
       char buffer[512];
       vecteur.resize(nbr_element);
       std::vector<element_t>::iterator it=vecteur.begin();
       while (!feof(pf_))
       {
          fgets(buffer,511,pf_);
          std::copy(it->first.begin(),it->first.end(),buffer);
          it->second = atoi(buffer+8);
       }
     
       std::stable_sort(vecteur.begin(),vecteur.end());
    }
     
    template<class callable_>
    void fonction(callable_ f_)
    {
       std::string file = directory + "fichier.txt";
       FILE *fp = fopen(file.c_str(),"r");
       boost::timer timer;
       f_(fp);
       double elapsed = timer.elapsed();
       std::cout<<"elapsed = "<<elapsed<<"\n";
     
       fclose(fp);
    }
     
     
    int main()
    {
       std::string s;
       fonction(read_1);
       fonction(read_2);
       fonction(read_3);
       fonction(read_3_bis);
       fonction(read_4);
       fonction(read_4_bis);
       fonction(read_5);
       fonction(read_5_bis);
       return 0;
    }
    J'obtiens comme temps :
    Citation Envoyé par Visual
    elapsed = 0.947
    elapsed = 0.892
    elapsed = 0.178
    elapsed = 0.174
    elapsed = 0.182
    elapsed = 0.175
    elapsed = 0.466
    elapsed = 0.453
    Citation Envoyé par GCC
    elapsed = 1.152
    elapsed = 0.88
    elapsed = 0.178
    elapsed = 0.187
    elapsed = 0.191
    elapsed = 0.191
    elapsed = 0.663
    elapsed = 0.659
    read_1 : tel que tu l'as présenté
    read_2 : ce que tu as présenté sans les std::string intermédiaire
    read_3 : 2 vecteurs avec boos::array<char,8> à la place de std::string + reserve
    read_3_bis : idem read_3 mais avec des std::vector::resize et un itérateur à la place d'un reserve+push_back
    read_4 : un seul vecteur avec un élément std::pair<boost::array<char,8>, int>
    read_4_bis : idem read_4 mais avec resize + itérateur ) la place de reserve + push_back
    read_5 : idem read_4 + stable_sort
    read_5_bis : idem read_4_bis + stable_sort
    Il n'est pas très honnête de comparer brutalement les std::vector aux std::map car un map est un conteneur plus 'évolué' : la recherche sur une map est moins cher que sur un vecteur, cette différence de cout étant payée à la construction. C'est pour cela que j'ai mis les tests 5 et 5_bis avec le tri en plus. Là, les temps de recherche redeviennent comparable.

    Conclusion : vecteur toujours plus performant. Si ensuite la recherche n'est pas pénalisante, utiliser uniquement un vecteur. Sinon, faire un tri : vecteur + tri reste moins cher que map.


    Il resterait probablement à travailler sur la lecture et la conversion (atoi)

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 53
    Par défaut
    C'est parfait !!! Merci 3DArchi !!! J'ai utilisé la méthode 3, qui prends que 2ms au lieu des 20ms auparavant. Cela reste long pour ce que c'est bien bien mieux qu'avant donc j'en suis content !!! Merci encore

  7. #7
    Membre Expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Par défaut
    Citation Envoyé par gilims Voir le message
    C'est parfait !!! Merci 3DArchi !!! J'ai utilisé la méthode 3, qui prends que 2ms au lieu des 20ms auparavant. Cela reste long pour ce que c'est bien bien mieux qu'avant donc j'en suis content !!! Merci encore
    2 ms, c'est effectivement long. Maintenant, peut-être que tu devrais commencer par copier l'intégralité du fichier en mémoire, histoire d'éviter un trop grand nombre de lectures (si toutefois ce problème se pose).

    Et bien sûr, t'assurer que tu travailles en release et pas en debug. Mais je pense que je n'ai pas à te dire ça

    @3DArchi : la plupart des compilateurs récents implémentent l'optimisation small buffers, ce qui fait que les string de taille réduite (sur VC++, length() < 16) ne nécessitent pas d'allocation mémoire. Avec le réserve qui va bien en début de boucle, et la lecture de l'ensemble du fichier upfront, on peut éliminer toutes les allocations dans la boucle (dans le cas ou on utilise un std::vector<> ; dans le cas ou on utilise un std::map<>, il faudra peut-être prévoir un allocateur spécialisé).
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 53
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    Et bien sûr, t'assurer que tu travailles en release et pas en debug. Mais je pense que je n'ai pas à te dire ça
    Cela va de soi !!!!


    Citation Envoyé par Emmanuel Deloget Voir le message
    2 ms, c'est effectivement long. Maintenant, peut-être que tu devrais commencer par copier l'intégralité du fichier en mémoire, histoire d'éviter un trop grand nombre de lectures (si toutefois ce problème se pose).
    Oui, c'est bien long mais toujours moins que mes 20 ms initiales !!
    Comment faire pour tout charger en mémoire, sachant que le fichier fait quand même 220 Ko ??!!!!


    Par contre, le std::copy(cles.begin(),cles.end(),buffer); ne fonctionne pas chez moi. En affichant les données, il me donne quelque chose du style ^$ ou pire encore. J'ai résolu le probleme en mettant cles.assign(" "), mais je ne suis pas sur de bien m'y prendre.

  9. #9
    Membre Expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Par défaut
    Citation Envoyé par gilims Voir le message
    Oui, c'est bien long mais toujours moins que mes 20 ms initiales !!
    Comment faire pour tout charger en mémoire, sachant que le fichier fait quand même 220 Ko ??!!!!
    Mince, tu programmes en C++ en utilisant la librairie standard sur un PC qui a moins de 128 Ko de RAM ?

    Sérieux : 220 Ko, c'est pas vraiment un problème impossible à résoudre

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    std::ifstream infile(file.c_str());
    infile.seekg(0, std::end);
    std::size_t filesize = infile.tellg();
    infile.seekg(0, std::beg);
    std::vector<char> buffer(filesize);
    infile.read(&buffer.front(), buffer.size());
    infile.close(); // fichier lu, fichier fermu.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 53
    Par défaut

    Je sais je sais, ma question était quelque peu simplette !!!
    Je vais regarder ca de plus près

    Merci encore !

  11. #11
    Membre Expert
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    @3DArchi : la plupart des compilateurs récents implémentent l'optimisation small buffers, ce qui fait que les string de taille réduite (sur VC++, length() < 16) ne nécessitent pas d'allocation mémoire. Avec le réserve qui va bien en début de boucle, et la lecture de l'ensemble du fichier upfront, on peut éliminer toutes les allocations dans la boucle (dans le cas ou on utilise un std::vector<> ; dans le cas ou on utilise un std::map<>, il faudra peut-être prévoir un allocateur spécialisé).
    s/compilateur/bibliothèques standard/

    Btw, chargé un fichier en mémoire c'est pas une bonne idée, c'est à l'OS (en théorie) de gérer ce genre de chose... (et si il le gére ça devient redondant). Malheureusement... le kernel à du s'adapter aux bétises de l'userland...

  12. #12
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Citation Envoyé par Emmanuel Deloget Voir le message
    @3DArchi : la plupart des compilateurs récents implémentent l'optimisation small buffers, ce qui fait que les string de taille réduite (sur VC++, length() < 16) ne nécessitent pas d'allocation mémoire. Avec le réserve qui va bien en début de boucle, et la lecture de l'ensemble du fichier upfront, on peut éliminer toutes les allocations dans la boucle (dans le cas ou on utilise un std::vector<> ; dans le cas ou on utilise un std::map<>, il faudra peut-être prévoir un allocateur spécialisé).
    Effectivement, je n'ai pas pensé à cette optimisation. Si je trouves le temps, j'essaierais de remettre des string et voir s'il y a une différence.
    De ce que je comprend, le fichier est un fichier de données 'stables' généré par le po et charger à l'init. Faudrait probablement regarder dans de la sérialisation binaire. Ce devrait pouvoir être encore une piste d'amélioration.

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    Novembre 2009
    Messages
    53
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2009
    Messages : 53
    Par défaut
    De ce que je comprend, le fichier est un fichier de données 'stables' généré par le po et charger à l'init. Faudrait probablement regarder dans de la sérialisation binaire. Ce devrait pouvoir être encore une piste d'amélioration.
    ... c'est du chinois pour moi !!! ^^

  14. #14
    Membre Expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Par défaut
    Citation Envoyé par Goten Voir le message
    s/compilateur/bibliothèques standard/

    Btw, chargé un fichier en mémoire c'est pas une bonne idée, c'est à l'OS (en théorie) de gérer ce genre de chose... (et si il le gére ça devient redondant). Malheureusement... le kernel à du s'adapter aux bétises de l'userland...
    Pas tout à fait d'accord :

    1) le kernel n'a pas à te dire s'il le fait ou non. Du coup, selon la configuration, tu peux avoir un comportement de ton programme radicalement différent.

    2) quand bien même il le fait, tu peux aussi vouloir libérer au plus vite la ressource fichier sous-jacente - ce que le kernel ne fera pas si tu ne lui en donne pas l'ordre.

    3) et que se passe-t-il si le kernel le fait et qu'on ne souhaite pas que ça arrive ? Dans mon poste précédent, j'ai été confronté à un problème de ce type : une carte SD micro dont le contenu était entièrement lu pas l'OS (Android), placé en cache, et après ça, l'OS n'allait plus lire la carte. Problème : cette carte n'était pas passive, et les valeurs lues étaient censée refléter un état.

    Il y a donc un intérêt fort à lire le fichier upfront et à ne pas laisser le kernel le faire, comme on peut vouloir faire exactement le contraire. Les IO sont un monde sensible, qui doit être le plus contrôlable possible. Dans une grande majorité des cas, ce que va proposer l'OS va convenir au développeur. Dans d'autres cas, plus rares, ce ne sera pas le cas - on doit donc avoir la possibilité de passer outre.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  15. #15
    Membre Expert
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Par défaut
    A vraie dire c'était mon côté kernel developpeur qui parlait, et c'était plus . La gestion du cache de l'IO disque c'est pas trivial, normalement c'est au kernel de le gérer, seulement on c'est retrouvé avec des développeurs (userland) qui y'allait à grand coup de malloc pour charger le fichier en mémoire et on se retrouvé avec des perfs dégradé, du coup l'OS s'est adapter et à changer sa façon de faire, seulement, c'est chiant parce que c'est pas sensé être dans ce sens. (oui mon post était plus coup de gueule un message à faire passer qu'autre chose :p, je suis d'accord avec toi de toute façon)

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. temps de calcul RSA
    Par othland dans le forum Langages de programmation
    Réponses: 2
    Dernier message: 13/03/2006, 11h16
  2. Temps de calcul d'un algo
    Par Rémiz dans le forum VB 6 et antérieur
    Réponses: 7
    Dernier message: 23/12/2005, 13h52
  3. temps de calcul sius VC++ !!
    Par Axiome dans le forum MFC
    Réponses: 16
    Dernier message: 13/12/2005, 09h57
  4. Temps de calcul avec deux écrans
    Par Shaga dans le forum OpenGL
    Réponses: 2
    Dernier message: 14/11/2005, 09h24
  5. temps de calculs extremement long !!
    Par salseropom dans le forum C++
    Réponses: 9
    Dernier message: 19/01/2005, 20h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo