• # Un problĂšme de tampon

    Posté par  . É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.