Le cas testé ici ne correspond pas au cas d'usage auquel les outils C++ utilisé ici sont pertinent. Les
Et vu que le contenu de lien n'essaye pas du tout de comprendre ou d'apporter des pistes de réflexion, même pas un petit questionnement, ba c'est pas super intéressant.
Par exemple, dans les tests des fonctions C une pré-allocation de la string de destination est faite une fois et de la bonne taille avant de la remplir avec le contenu du fichier. Chose qui n'est pas faite dans les cas d'utilisation des stream C++.
Dans les version C++, il y a sûrement de multiple réallocation de la string … ce qui est beaucoup plus coûteux qu'une première allocation d'une taille suffisante.
Pour mieux comparer, il faudrait également faire des préallocation à la bonne taille de la string de destination.
D'ailleurs, le test ne compare pas les performances des stream C++ et des read(posix) et fread(libc). Mais compare plusieurs méthodes pour charger entièrement un fichier dans une string.
Dans d'autres cas (très gros fichiers) la méthodes qui consiste à charger entièrement le fichier en mémoire ne serait pas utilisable.
Personellement j'ai pu faire plus rapide avec moins de code en C++ pour un usage un peu similaire (écriture très rapide de fichiers csv). Le C++ permet de facilement configurer un buffer d'écriture et d'avoir une API simple et rapide pour écrire les données.
Par contre ce n'est pas ifstream/ofstream qu'il faut utiliser pour ça. C'est un peu comme si on disait que lire un fichier dans une string en utilisant fscanf est lent. C'est juste pas la bonne fonction pour ça.
D'autre part, en C/UNIX, on peut aussi faire plus rapide, par exemple avec mmap().
Et je retombe sur des temps très similaire au fread ou read. Plutôt un tout petit peut plus lent sur les petits fichiers, et un peu plus rapide sur les gros fichiers.
./test 1M 2M 4M 8M 16M 32M
File 1M
C++ istreambuf_iterator : .......... 3445 us
C++ stream::rdbuf : .......... 432 us (7.97)
C++ ifstream_read : .......... 137 us (25.15)
libc fread : .......... 137 us (25.15)
POSIX read : .......... 134 us (25.71)
File 2M
C++ istreambuf_iterator : .......... 7076 us
C++ stream::rdbuf : .......... 1319 us (5.36)
C++ ifstream_read : .......... 265 us (26.70)
libc fread : .......... 270 us (26.21)
POSIX read : .......... 262 us (27.01)
File 4M
C++ istreambuf_iterator : .......... 13638 us
C++ stream::rdbuf : .......... 2429 us (5.61)
C++ ifstream_read : .......... 596 us (22.88)
libc fread : .......... 601 us (22.69)
POSIX read : .......... 583 us (23.39)
File 8M
C++ istreambuf_iterator : .......... 27491 us
C++ stream::rdbuf : .......... 5478 us (5.02)
C++ ifstream_read : .......... 1984 us (13.86)
libc fread : .......... 1983 us (13.86)
POSIX read : .......... 1986 us (13.84)
File 16M
C++ istreambuf_iterator : .......... 54919 us
C++ stream::rdbuf : .......... 10920 us (5.03)
C++ ifstream_read : .......... 4773 us (11.51)
libc fread : .......... 4789 us (11.47)
POSIX read : .......... 4805 us (11.43)
File 32M
C++ istreambuf_iterator : .......... 109104 us
C++ stream::rdbuf : .......... 36073 us (3.02)
C++ ifstream_read : .......... 9698 us (11.25)
libc fread : .......... 9748 us (11.19)
POSIX read : .......... 9660 us (11.29)
# Titre clickapute
Posté par Mimoza . Évalué à 2.
Ça ne fait que décrédibiliser le contenu et, pour ma part, met une grosse réserve pour cliquer sur le lien.
[^] # Re: Titre clickapute
Posté par fearan . Évalué à 5. Dernière modification le 27 avril 2022 à 12:51.
le titre est exactement ce que tu décris ; aucune surprise, les fonction C de bases font mieux que l'approche C++, mais nécessitent plus de code.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Le résultat ne m'a pas étonné du tout
Posté par xoddark . Évalué à 3.
Le cas testé ici ne correspond pas au cas d'usage auquel les outils C++ utilisé ici sont pertinent. Les
Et vu que le contenu de lien n'essaye pas du tout de comprendre ou d'apporter des pistes de réflexion, même pas un petit questionnement, ba c'est pas super intéressant.
Par exemple, dans les tests des fonctions C une pré-allocation de la string de destination est faite une fois et de la bonne taille avant de la remplir avec le contenu du fichier. Chose qui n'est pas faite dans les cas d'utilisation des stream C++.
Dans les version C++, il y a sûrement de multiple réallocation de la string … ce qui est beaucoup plus coûteux qu'une première allocation d'une taille suffisante.
Pour mieux comparer, il faudrait également faire des préallocation à la bonne taille de la string de destination.
[^] # Re: Le résultat ne m'a pas étonné du tout
Posté par xoddark . Évalué à 3.
D'ailleurs, le test ne compare pas les performances des stream C++ et des read(posix) et fread(libc). Mais compare plusieurs méthodes pour charger entièrement un fichier dans une string.
Dans d'autres cas (très gros fichiers) la méthodes qui consiste à charger entièrement le fichier en mémoire ne serait pas utilisable.
[^] # Re: Le résultat ne m'a pas étonné du tout
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Personellement j'ai pu faire plus rapide avec moins de code en C++ pour un usage un peu similaire (écriture très rapide de fichiers csv). Le C++ permet de facilement configurer un buffer d'écriture et d'avoir une API simple et rapide pour écrire les données.
Par contre ce n'est pas ifstream/ofstream qu'il faut utiliser pour ça. C'est un peu comme si on disait que lire un fichier dans une string en utilisant fscanf est lent. C'est juste pas la bonne fonction pour ça.
D'autre part, en C/UNIX, on peut aussi faire plus rapide, par exemple avec mmap().
[^] # Re: Le résultat ne m'a pas étonné du tout
Posté par lmg HS (site web personnel) . Évalué à 3.
Dans le genre, après l'allocation unique, je serai parti sur
std::ifstream::read()
aussi. Histoire de comparer des choses similaires…[^] # Re: Le résultat ne m'a pas étonné du tout
Posté par xoddark . Évalué à 2.
Effectivement,
j'ai fait un test rapide en utilisant un std::ifstream::read() tell que présenté dans la page cppréférence : https://en.cppreference.com/w/cpp/io/basic_istream/read
Et je retombe sur des temps très similaire au fread ou read. Plutôt un tout petit peut plus lent sur les petits fichiers, et un peu plus rapide sur les gros fichiers.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.