Sur n'importe quel type de fichier je sais pas, SQLite étant open-source tu peux étudier comment ils s'y prennent pour réussir à être plus rapide, mais je pense qu'ils y arrivent grâce à leur structure de fichier rendant le besoin en accès bien plus spécifique.
Mais c'est plutôt étonnant d'en arriver à ce besoin d'optimisation, tu es sûr que c'est ce dont tu as besoin ? Tu peux pas concevoir ton programme pour gagner ailleurs, ou effectuer moins d'accès disque ?
- Edité par romantik 12 avril 2019 à 9:56:50
Dream on, Dream on, Dream until your dream comes true
Le mieux est de lire/écrire le fichier d'un seul coup : les disques durs / clés / DVD, sont optimisés pour du séquentiel. C'est la que tu auras les meilleures performances.
Si ton fichier a une taille raisonnable, prépare le en RAM, puis ensuite tu le write en un seul coup.
Si tu write les données petit à petit, en général, tu iras moins vite. Si tu read les données octets par octets tu iras moins vite.
Pire, si tu fermes ton fichier et le rouvre ensuite pour rajouter des données, tu iras encore moins vite, et encore pire depuis Windows 10 qui embarque un antivirus qui scanne les fichiers une fois fermés, autrement dit, si tu close ton fichier, il est scanné, si tu l'ouvres et que tu le fermes sans arrêt, tu t'effondres en perf.
bacelar, il y a quand même des règles absolues: il faut privilégier de lire ou écrire par gros paquets séquentiels de tailles compatibles avec le cache.
Faire des micro-lectures ou écritures dans tous les sens (accès dit aléatoire) est vite une plaie.
Évidemment aller vite avec un code buggué ne sert à rien.
Quant à des mesures sur des fichiers c'est vite compliqué selon le système sur lequel on bosse. Entre un SSD local sur une machine non partagée, et une baie GPFS dimensionnée pour le capacitatif (et pas les IO p/s) avec des nombreux utilisateurs en plus de soi... Mesurer est complexe. Il y a des moyens, mais c'est complexe. Par contre, les généralités restent valables. Bien sûr faut pondérer p/r aux traitements faits pour savoir quand ça vaut la peine ou pas.
Lectures parallèles sur des SSD NVME entre plein d'autres.
On est tous d'accord, @Fvirtman, @lmghs, seul la mesure en condition réel est fiable.
Juste pour me faire l'avocat du diable : parce que tu crois qu'un débutant va s'amuser à faire des lectures en parallèle sur des SSD NVME ???.
Tu n'as absolument pas tort dans ce que tu dis.
Mais je crois que, quand on s'adresse à des débutants, il arrive forcément un moment où il est préférable fournir des explications simples permettant de comprendre, quitte à ce qu'elles soient fausses dans une "certaine mesure" (ou, du moins, "pas tout à fait juste") et de tirer des "règles générales" de ces explications, quitte à ce qu'elles soient "forcément" un peu faussées.
"Par la suite", il sera "toujours temps", si la personne se trouve dans une situation dans laquelle la règle générale ne s'applique effectivement pas, d'entrer dans les détails plus complexes et d'en tirer la conclusion qui s'impose : tu es face à une exception à la règle.
Parce que, l'un dans l'autre, on se rend compte -- avec la pratique -- qu'il y a toujours (ou du moins, qu'il y a souvent) des exceptions, des situations "qui font que" les "règles générales" puissent ne pas s'appliquer.
Mais on croise beaucoup trop de développeurs qui, à cause des exceptions -- qui ne se présentent pourtant pas tous les jours, loin s'en faut -- décident purement et simplement de ne pas s'intéresser aux règles générales, et pire encore, de ne pas s'inquiéter s'ils en viennent à ne pas les respecter, sous prétexte que "bah, je suis face à une exception"
Que ce prétexte soit valable ou non n'a pas sa place dans la discussion. Mais les développeur qui nous sortent ce prétexte oublient trop facilement (l'ont-ils seulement jamais su ?, en ont-ils seulement conscience?) que si le fait de déroger à une règle peut -- effectivement -- leur "faciliter la vie" de manière ponctuelle, il met surtout en place "tout le nécessaire" pour les confronter à des problèmes bien plus difficiles à résoudre sur le "long terme".
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Moi, je pense qu'il est bien plus nécessaire de faire comprendre aux débutants qu'il n'y jamais de règles absolues en matière d'optimisation et qu'il faut toujours prendre la peine de mesurer les performances AVANT de saloper leur code pour un gain putatif de performance dans un contexte totalement indéfini.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Je dis juste qu'avant de venir parler d'exceptions qui "invalident" les règles, il faut leur faire comprendre que l'on a beaucoup plus d'avantages à connaitre et à appliquer les règles générales et beaucoup plus d'inconvénients à les ignorer sous prétexte ... qu'il y a des exceptions.
D'ailleurs, il faut aussi leur faire comprendre que, de manière générale, l'optimisation est la dernière dont il faut s'inquiéter: la priorité étant d'avoir quelque chose qui fonctionne.
Et, dans le domaine des optimisations, l'accès aux fichiers est très loin en termes de priorités, car, avant de commencer à s'en inquiéter, il y a beaucoup de choses à faire pour (espérer) améliorer les performances (revoir les algorithme et les structures de données, éviter les copies inutiles, éviter les cache misses, et bien d'autres encore)
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
rapidité // lecture fichier
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html