Ce n'est pas si vrai que ça. C'est surtout un bench du sous système IO de la lib du langage. Et cela peut être très mal fait.
C'est vrai. Mais c'est quelque chose d'assez dure à mesurer, les I/O font toujours parti des aspects les plus dure à benchmarker d'un programme car elles sont très sensibles au effets de bords ( cache du kernel, utilisation de la mémoire, block size, ... )
Si tu rajoutes à ça le fait que la plupart des langages te donne à la fois leur propre librairie et un accés direct à l'API POSIX open/read/write de l'OS.
Tu obtiens une situation où ce que tu mesures est bien souvent l'efficacité d'un pattern d'accés plutot que la performance de ta lib en question :)
. Devoir lire une grande quantité de fichier (10 000 ?) de taille moyenne (1 Mo ?) dans une arborescence, et d'écrire autant de fichiers (avec un checksum bidon dedans par exemple).
Ça pourrait être trés interessant en effet. Peut être un benchmark à leur proposer.
La même chose concernant le taux de request par seconde sur un seul et même socket: le classique C10K problem.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
C'est vrai. Mais c'est quelque chose d'assez dure à mesurer, les I/O font toujours parti des aspects les plus dure à benchmarker d'un programme car elles sont très sensibles au effets de bords ( cache du kernel, utilisation de la mémoire, block size, ... )
Si tu rajoutes à ça le fait que la plupart des langages te donne à la fois leur propre librairie et un accés direct à l'API POSIX open/read/write de l'OS.
Tu obtiens une situation où ce que tu mesures est bien souvent l'efficacité d'un pattern d'accés plutot que la performance de ta lib en question :)
Ça pourrait être trés interessant en effet. Peut être un benchmark à leur proposer.
La même chose concernant le taux de request par seconde sur un seul et même socket: le classique C10K problem.