Discussion :

[Invité]

Bonjour

Je cherche actuellement à optimiser mon programme qui lit des données dans un fichier, j'ai lu certains articles à ce sujet, mais cela ne m'a pas vraiment éclairé.

Voici la situation :

Les fichier sont des fichiers de données brutes, organisées selon un structure précise : d'abord une date, puis un char, puis un int, et deux doubles, etc, le tout complété par une séquence de fin de bloc (\n\t\0\n). Seulement la plus grande partie de ces blocs est de taille variable.

Chaque fichier contient plusieurs de ces blocs, classés selon leur date (un fichier contient une heure d'enregistrement).

Mon programme et codé avec Qt, j'ustilise donc QFile et QDataStream pour lire et écrire le fichier (la date mentionnée plus haut est en fait un QTime sérialisé par le QDataStream). C'est fait de façon assez basique (un peu dans l'urgence) avec la méthode bétémé : stream >> QTime >> char >> int >> double etc.

La taille variable des blocs implique que je doive les lire en entier, même si je ne m'intéresse qu'à ceux d'après, pour arriver aux suivants.

Le problème est qu'actuellement, un fichier comprenant une heure complète prend à peu près 3 secondes à se lire, je vous laisse faire le compte lorsque que je charge 4 jours d'un coup.

Donc, j'aimerais savoir s'il existe un moyen d'accélérer la lecture de mes fichiers, une autre façon de coder à laquelle je n'aurais pas pensé ? La STL ou une autre librairie serait-elle plus performante ? Ou dois-je revoir la structure de mes fichier si je veux éviter les longues attentes ?

Question subsidiaire : devrais-je envisager de remplacer mon système "fait main" par un SGBD ? Sachant que la quantité de données enregistrées peut atteindre 500 Mo par jour, mais que seule l'application concernée y accède. J'ai vu par exemple SQLite, très intéressant pour son intégration dans l'application, mais que la taille de mes données ne rend pas viable.

Cordialement.

[Emmanuel Deloget]

Question subsidiaire : devrais-je envisager de remplacer mon système "fait main" par un SGBD ? Sachant que la quantité de données enregistrées peut atteindre 500 Mo par jour, mais que seule l'application concernée y accède. J'ai vu par exemple SQLite, très intéressant pour son intégration dans l'application, mais que la taille de mes données ne rend pas viable.

Cordialement.

Pourquoi pas ? Si tu génère 500 Mo de données sur disque, qu'est-ce qui te fait croire que sqlite sera plus lent à les gérer que toi ?

Par contre, j'ai un doute qui est d'une tout autre nature : 500 Mo par jour, ça représente combien d'enregistrements par seconde ? Avec un enregistrement de taille moyenne située vers 100 octets, j'arrive à 60 enregistrements par secondes, ce qui est tout à fait tenable avec sqlite (pour autant que tu désactive l'insertion transactionnelle des éléments, qui ralenti fortement l'insertion dans le cas nominal).

[imperio]

sqlite me semble aussi etre une solution viable. Mais si tu preferes continuer de le faire "a la main", vu que tu utilises Qt je pense que tu devrais tout lire d'un coup, faire un split sur la qstring obtenu pour obtenir une qlist et parser chaque element de cette qlist. Je pense que ca irait plus vite, en tout cas je suis curieux de le savoir. La lecture du fichier sera-t-elle plus longue que les algos de qt pour spliter les donnees ? Grande question

[Invité]

Pourquoi pas ? Si tu génère 500 Mo de données sur disque, qu'est-ce qui te fait croire que sqlite sera plus lent à les gérer que toi ?

Le problème que je suppose avec QSLite ne se pose pas au niveau de la vitesse mais de la taille du fichier de données (que ce SGBD ne peut pas fractionner, d'après ce que j'ai lu).

Par contre, j'ai un doute qui est d'une tout autre nature : 500 Mo par jour, ça représente combien d'enregistrements par seconde ? Avec un enregistrement de taille moyenne située vers 100 octets, j'arrive à 60 enregistrements par secondes,

En fait, mon programme génère un enregistrement toutes les 10 secondes à peu près. Il s'agit, entre autre informations, de 2 séries de réels représentant des courbes.

je pense que tu devrais tout lire d'un coup, faire un split sur la qstring obtenu pour obtenir une qlist et parser chaque element de cette qlist. Je pense que ca irait plus vite, en tout cas je suis curieux de le savoir

Ok, j'essaierais ça demain, merci

[Emmanuel Deloget]

Ce qui veut dire que tu fractionnes les données dans tes fichiers à toi ? Ce n'est pas tout à fait anormal, vu la vitesse à laquelle ta base de donnée grandit

Bon, effectivement, SQLite ne sait pas faire ça de manière automatique. Mais ça ne veut pas dire qu'il ne sait pas faire. En fait, il sait faire très bien, mais ça demande un peu plus de travail. L'idée est de passer par sqlite3_open_v2(), et de fournir à sqlite un VFS custom. Un exemple, qui scinde la DB en plusieurs fichiers afin de passer outre la restriction de taille, est donné en exemple sur le site de sqlite.org. Ce n'est pas nécessairement simple, mais c'est pas mal documenté

Sinon, tu peux toujours tester d'autres solutions, plus robustes mais aussi plus lentes, comme mysql ou postgresql. Ceci dit, 500 MB par jour, ce n'est pas si énorme que ça. En fait, je pense que n'importe quel système de base de donnée est tout à fait capable de gérer et d'indexer ça. Reste à utiliser le bon backend (avec postgresql, la taille des bases de données est limitée par la taille du disque ; il est possible de synchroniser plusieurs instances afin d'avoir une réplication des bases, ce qui permet de ne pas perdre de données). Et oui, parce qu'en plus des données que tu dois traiter, je suppose que tu dois aussi t'assurer de leur validité, et essayer de ne pas les perdre Un SGBD traditionnel te fournira ce type de service, que tu n'auras pas besoin de réinventer

[JolyLoic]

Pourquoi pas ? Si tu génère 500 Mo de données sur disque, qu'est-ce qui te fait croire que sqlite sera plus lent à les gérer que toi ?

L'expérience ?

En tout cas, selon la mienne, si on vaut gérer des données de manière avancées, faire des indexages, des jointures, des accès synchronisés, du commit ou rollback, alors, oui, un SGDB est justifié. Mais si on veut faire des traitements relativement linéaires en masse avec des grosses données, rien ne remplace une lecture à la main (j'ai souvenir d'un traitement qui durait environ 40h sur un ETL sur de grosses machines, et 40 minutes en lisant des fichiers plats à la main sur un portable de base).


Sinon, pour revenir au problème initial, il y a deux voies de recherches :
- Utiliser des API plus performantes (par exemple, sous windows, utiliser des entrées/sorties asynchrones)
- Utiliser un format de fichier plus approprié, par exemple en ajoutant un index.

[Invité]

je pense que tu devrais tout lire d'un coup, faire un split sur la qstring obtenu pour obtenir une qlist et parser chaque element de cette qlist. Je pense que ca irait plus vite, en tout cas je suis curieux de le savoir

Ok, j'essaierais ça demain, merci

J'ai dit n'importe quoi, je ne peux pas faire ça, vu la forme de mes enregistrements. Ou du moins, je pourrais bricoler sans trop de difficultés quelque chose qui y ressemble mais je ne pense pas que ça augmente les performances.

Donc, je récapitule la situation de façon plus claire :
Mon programme effectue des mesures (toutes les 10 secondes environs), qui se présentent sous forme de courbes (donc, 2 séries de nombres, la première pour les abscisses et la seconde pour les ordonnées associées). Ces mesure sont enregistrées dans des fichiers écrits à la main organisés de la manière suivante :

L'espace de stockage contient des dossiers chacun nommé par l'identifiant d'un mois (YYYY-MM). Chacun de ces dossiers contient d'autres dossiers nommé par le numéro du jour (DD). Chaque dossier de jour contient les fichiers d'enregistrement nommés par la plage d'heure qu'il contient (le dossier 14 contient les enregistrements de 14:00:00 à 14:59:59).

Fractionner mes données de cette manières a des avantages au niveau de la logistique des fichiers, par exemple lorsque l'on veut déplacer tels ou tels jours de l'historique sur une autre machine.

Un fichier est organisé de la manière suivante : les données sont écrites par un QDataStream, identifiées par l'heure d'enregistrement par une simple sérialisation : stream << QTime << char << int << double etc.

Ce sont donc des données binaires, et non pas texte, ce qui rend difficile la proposition de imperio. Il est toujours possible de bricoler quelque chose (en jonglant entre QString, QChar et QByte array), mais je doute (à l'instinct) que cela change beaucoup les choses.

La subtilité est qu'il y a trois fichier pour chaque heure, et que les seul qui posent problèmes sont ceux contenant les courbes (environs 20 Mo / heure). Les deux autres ne dépassant pas 250 Ko / heure (ensembles) ne posent pas ce problème de temps de lecture.

En la situation actuelle, je pencherais plutôt pour la solution de JolyLoic, mais j'y suis très peu familier, je vais donc me renseigner avant d'aller plus loin.

[white_tentacle]

Je ne connais pas les perfs de QDataStream. Mais 20Mo en 3 secondes, c’est pas terrible, il y a moyen de faire mieux avec un disque local.

Quelques remarques :
- le fichier est-il mappé en mémoire avant lecture ?
- le parcours impose-t-il de lire un bout d’un fichier, un bout de l’autre, etc ?
- la structure mémoire dans laquelle tu charges le contenu est-elle correctement optimisée ?

Et as-tu besoin de tout le contenu du fichier, ou seulement d’une partie ? Auquel cas la création d’un index est une énorme optimisation.

[koala01]

Salut,

Pour charger le fichier, tu pourrais sans doute te baser sur quelques entrée de la FAQ comme celle-ci ou encore celle-ci.

Seulement, cela ne résoudra peut etre qu'une partie du problème car il faudra compléter le traitement par une conversion des données brutes en données utilisables.

Cependant, si les fichiers sont sauvegardés au format binaire que le format est constant, tu devrais pouvoir faire les choses de manière assez rapide en lisant directement tout le fichier (hors en-tête) selon cette méthode et en faisant un "simple" transtypage du résultat en un tableau de ta structure.

Par exemple:
Il devrait etre "assez facile" de déterminer la taille que prend un QTime dans le fichier (ca doit etre documenté, ca, non question
Le premier lien que je t'ai donné vers la FAQ t'indique la manière de calculer la taille du fichier.

Tu pourrais donc partir du principe de créer un tableau de char de la taille complete du fichier, sous une forme proche de

Code :

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

1
2
3
4
/* j'aimerais éviter mais ca pourrait aller pour cela ;) */
char * tab = new char[filesize-sizeof(QTime)];
/* idéalement, on préférerait sans doute un */
std:vector<char> tab(fileSize-sizeof(QTime),'\0');

on lit l'ensemble en une seule grande instruction read, sous la forme de

Code :

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

1
2
3
std::ifstream file("fichier.dat",std::ios_base::binary);
file.seekg(sizeof(QTime), ios::beg);
file.read(&tab[0],filesize);

et l'on converti le tout "à la rache" dans un tableau de la structure ad-hoc avec un

Code :

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

LaStructure * result = reinterpret_cast<LaStructure*>(&tab[0]);

Ce n'est peut etre pas très beau comme code, mais, une structure qui est régulièrement répété dans ton fichier, tu devrais pouvoir avoir une lecture assez rapide de cette manière

[white_tentacle]

Ce n'est peut etre pas très beau comme code, mais, une structure qui est régulièrement répété dans ton fichier, tu devrais pouvoir avoir une lecture assez rapide de cette manière

Non mais utiliser un QDataStream est nettement plus propre : ça fait de la sérialisation correctement et cross-platform. Je ne reviendrai par sur cet aspect là personnellement.

Le problème de perf qu’il a résulte à mon avis d’une mauvaise utilisation, soit dans la lecture, soit dans la structure mémoire. Un google rapide montre que qdatastream semble avoir des perfs tout à fait normales (donc plus près des 70Mo/s que des 6Mo/s de l’op).