Celui-ci ajoute d'autres implémentations: la fonction memchr en C est équivamente, et il y a différentes implémentations dans différentes biblothèque C. Certaines plus lentes et certaines plus rapides que l'implemenation "naive" avec une simple boucle.
Cela a donné lieu à une discussion sur la mailing list du musl: https://www.openwall.com/lists/musl/2016/09/18/3 avec des liens supplémentaires vers d'autres cas ou des libraries C proposent une implémentation "optimisée" qui est en fait plus lente que l'implémentation triviale en C. D'ou la conclusion: on peut faire confiance au compilateur pour optimiser le code simple et lisible de façon pas trop mauvaise. Même si le compilateur n'est pas parfait et que les fonctions de la glibc sont très génériques, et souvent on peut écrire du code plus efficace, ce n'est pas la peine d'essayer de le faire systématiquement.
# Un autre benchmark
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Recherche de valeur dans un tableau et l'écosystème des compilateurs C++. Évalué à 6.
Celui-ci ajoute d'autres implémentations: la fonction memchr en C est équivamente, et il y a différentes implémentations dans différentes biblothèque C. Certaines plus lentes et certaines plus rapides que l'implemenation "naive" avec une simple boucle.
https://gms.tf/stdfind-and-memchr-optimizations.html
Cela a donné lieu à une discussion sur la mailing list du musl: https://www.openwall.com/lists/musl/2016/09/18/3 avec des liens supplémentaires vers d'autres cas ou des libraries C proposent une implémentation "optimisée" qui est en fait plus lente que l'implémentation triviale en C. D'ou la conclusion: on peut faire confiance au compilateur pour optimiser le code simple et lisible de façon pas trop mauvaise. Même si le compilateur n'est pas parfait et que les fonctions de la glibc sont très génériques, et souvent on peut écrire du code plus efficace, ce n'est pas la peine d'essayer de le faire systématiquement.