Sans surprise, c'est la raison qui est donnée par l'article : par défaut, stdout a un tampon. Les caractères ne sont envoyés que lorsqu'un caractère nouvelle ligne est trouvé (ou à partir d'un certain nombre max de caractère je suppose). C'est plus efficace. Ça regroupe.
Écrire dans un fichier, c'est un syscall. Écrire caractère par caractère, c'est un syscall par caractère, et ça, c'est lent.
Mais mais mais, ce n'est probablement pas souhaitable pour stderr, parce qu'on veut que les erreurs soient affichées sans attendre. Et aussi, normalement on n'affiche pas des tartines dans stderr, juste des messages d'erreurs, donc il n'y a pas vraiment besoin d'optimiser ça.
Sinon l'article a l'air intéressant, là je mentionne la raison mais l'article semble être une excellente trace écrite d'une belle investigation avec une explication de plein de choses en profondeur. Ne vous arrêtez pas à ce commentaire.
Ça tombe un peu à pic, je viens justement de rendre un processus qui était CPU-bound IO-bound et trois fois plus rapide juste en rendant une lecture de fichier bufferisée (et ce serait probablement plus que trois fois s'il n'y avait pas d'autres sources de lenteurs). Précédemment la lecture se faisait octet par octet, et ça, c'est mortel. Je me suis pour l'occasion formé au profiling d'application Java et je recommande chaudement async-profiler qui donne de beaux flame graphs qui, très important, contiennent aussi la partie système de l'exécution. Vous pourrez trouver les miens ici.
C'est un correctif de quelques caractères mais qui a demandé des heures d'investigations, et qui va avoir un sérieux impact aussi. Comme quoi, compter les lignes de codes pour évaluer les choses, ce n'est pas toujours la panacée, s'il y avait encore un doute à ce sujet…
# Un problème de tampon
Posté par raphj . Évalué à 10.
Sans surprise, c'est la raison qui est donnée par l'article : par défaut, stdout a un tampon. Les caractères ne sont envoyés que lorsqu'un caractère nouvelle ligne est trouvé (ou à partir d'un certain nombre max de caractère je suppose). C'est plus efficace. Ça regroupe.
Écrire dans un fichier, c'est un syscall. Écrire caractère par caractère, c'est un syscall par caractère, et ça, c'est lent.
Mais mais mais, ce n'est probablement pas souhaitable pour stderr, parce qu'on veut que les erreurs soient affichées sans attendre. Et aussi, normalement on n'affiche pas des tartines dans stderr, juste des messages d'erreurs, donc il n'y a pas vraiment besoin d'optimiser ça.
Sinon l'article a l'air intéressant, là je mentionne la raison mais l'article semble être une excellente trace écrite d'une belle investigation avec une explication de plein de choses en profondeur. Ne vous arrêtez pas à ce commentaire.
Ça tombe un peu à pic, je viens justement de rendre un processus qui était CPU-bound IO-bound et trois fois plus rapide juste en rendant une lecture de fichier bufferisée (et ce serait probablement plus que trois fois s'il n'y avait pas d'autres sources de lenteurs). Précédemment la lecture se faisait octet par octet, et ça, c'est mortel. Je me suis pour l'occasion formé au profiling d'application Java et je recommande chaudement async-profiler qui donne de beaux flame graphs qui, très important, contiennent aussi la partie système de l'exécution. Vous pourrez trouver les miens ici.
C'est un correctif de quelques caractères mais qui a demandé des heures d'investigations, et qui va avoir un sérieux impact aussi. Comme quoi, compter les lignes de codes pour évaluer les choses, ce n'est pas toujours la panacée, s'il y avait encore un doute à ce sujet…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.