tiens, j'ai suivi le lien et je note ça que j'avais loupé dans l'histoire des libc :
Note that previous versions of this comparison included eglibc rather than glibc, mainly since Debian-based distributions were using the eglibc fork during the time in which glibc was essentially unmaintained. Since most of eglibc has been merged back into glibc and eglibc is being discontinued, the comparison has been updated based on glibc.
Au passage, on remarque que (e)glibc est bien plus gourmande en mémoire dans la comparaison des auteurs de musl, mais est environ 2 fois plus rapide (à ~30% près) sur une bonne partie des fonctions importantes (allocation/libération mémoire, création/suppression des threads, etc...) à quelques exceptions près.
J'aime bien le côté tout UTF-8 par défaut et du coup une gestion plus performante ce cet encodage par musl, mais vu le nombre d'incompatibilité avec les applis utilisant (malheureusement) les anciens encodages, je me dit que pas mal ne doivent plus tourner (l'occasion de se pousser le cul pour tout remettre tout ces beaux codes tous libres en UTF ?).
Elle a des côtés plus résistant au crash qui semblent prometteur dans certains cas d'après ce tableau. Vu les incompatibilité et les problèmes encore présents d'une part et d'autre, il vaudra mieux dans beaucoup de cas attendre les évolutions à venir avant de déterminer si un changement serait une bonne idée ? Intéressant de savoir que ça existe en tout cas.
[^] # Re: Fonctionnalités clées.
Posté par tao popus . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 2.
tiens, j'ai suivi le lien et je note ça que j'avais loupé dans l'histoire des libc :
Note that previous versions of this comparison included eglibc rather than glibc, mainly since Debian-based distributions were using the eglibc fork during the time in which glibc was essentially unmaintained. Since most of eglibc has been merged back into glibc and eglibc is being discontinued, the comparison has been updated based on glibc.
Au passage, on remarque que (e)glibc est bien plus gourmande en mémoire dans la comparaison des auteurs de musl, mais est environ 2 fois plus rapide (à ~30% près) sur une bonne partie des fonctions importantes (allocation/libération mémoire, création/suppression des threads, etc...) à quelques exceptions près.
J'aime bien le côté tout UTF-8 par défaut et du coup une gestion plus performante ce cet encodage par musl, mais vu le nombre d'incompatibilité avec les applis utilisant (malheureusement) les anciens encodages, je me dit que pas mal ne doivent plus tourner (l'occasion de se pousser le cul pour tout remettre tout ces beaux codes tous libres en UTF ?).
Elle a des côtés plus résistant au crash qui semblent prometteur dans certains cas d'après ce tableau. Vu les incompatibilité et les problèmes encore présents d'une part et d'autre, il vaudra mieux dans beaucoup de cas attendre les évolutions à venir avant de déterminer si un changement serait une bonne idée ? Intéressant de savoir que ça existe en tout cas.