Il existe un dépôt signal-slot-benchmarks sur GitHub regroupant une trentaine de bibliothèques au sein d'un benchmark global permettant d'avoir un point de comparaison des performances des unes et des autres. C'est un bon point de départ.
Un benchmark est rarement un bon point d'entrée je trouve et le reste de ton journal montre en partie pourquoi. Pour moi ce qui est important c'est moins de connaitre la performance (déjà qu'est-ce que l'on met derrière la performance ?), mais la philosophie derrière.
Ta bibliothèque est bidirectionnelle orientée jeu avec 2 aspects importants : possibilité de modifier dynamiquement et à haute fréquence les connexions signal/slot et le mono-threading pour ne pas payer le coût du thread-safe par défaut.
Ce genre de petites descriptions sont pour moi bien plus intéressantes car elles donnent une bonne idée de à quoi s'attendre en terme de fonctionnalité et en terme de performance. Ça limite aussi les usages à contre-emploi.
Par exemple, iscool::signals garantit que les fonctions soient appelées dans l'ordre dans lequel elles ont été inscrites. C'est juste un choix d'implémentation (sur lequel nous comptions dans nos jeux) mais pas une qualité intrinsèque d'un système de signaux et de slots.
Tu as regardé si c'était l'ordre inverse (comme une pile) ou stable ? Et surtout il me semble qu'il y a un corollaire à ça : l'ordre des exécutions contraint la réduction des données en retour. S'il n'est pas prédictible la réduction que tu applique aux retours de tes signaux doit être commutatif.
bs2, ics, jls, lfs, lss, mws, nes, nod, nss, psg, vdk et wnk permettent de savoir si un signal a au moins un slot. Les autres ne le permettent pas.
Je me doute que ça répond à un besoin, mais je vois ça comme un anti-pattern. Pour moi le signal-slot est là pour avoir un découplage entre le signal et le slot. Sinon autant utiliser des callbacks. Mais je dirais aussi la même chose pour le retour des signaux.
J'aurais pensé que les signal/slot est un pattern unidirectionnel qui permet à un « bout de code » de signaler 0, 1 ou plus d'autres fonctions. Il par rapport à l'appel direct de méthode, il permet un dispatch dynamique et par rapport aux callback, il permet principalement une simplification (le slot n'a pas à gérer ses clients) ce qui apporte un meilleur découplage.
Mais c'est ma vision probablement biaisée et ma lecture du pattern observable.
# Remarques
Posté par barmic 🦦 . En réponse au journal Tests de bibliothèques signal-slot en C++. Évalué à 7.
Un benchmark est rarement un bon point d'entrée je trouve et le reste de ton journal montre en partie pourquoi. Pour moi ce qui est important c'est moins de connaitre la performance (déjà qu'est-ce que l'on met derrière la performance ?), mais la philosophie derrière.
Ta bibliothèque est bidirectionnelle orientée jeu avec 2 aspects importants : possibilité de modifier dynamiquement et à haute fréquence les connexions signal/slot et le mono-threading pour ne pas payer le coût du thread-safe par défaut.
Ce genre de petites descriptions sont pour moi bien plus intéressantes car elles donnent une bonne idée de à quoi s'attendre en terme de fonctionnalité et en terme de performance. Ça limite aussi les usages à contre-emploi.
Tu as regardé si c'était l'ordre inverse (comme une pile) ou stable ? Et surtout il me semble qu'il y a un corollaire à ça : l'ordre des exécutions contraint la réduction des données en retour. S'il n'est pas prédictible la réduction que tu applique aux retours de tes signaux doit être commutatif.
Je me doute que ça répond à un besoin, mais je vois ça comme un anti-pattern. Pour moi le signal-slot est là pour avoir un découplage entre le signal et le slot. Sinon autant utiliser des callbacks. Mais je dirais aussi la même chose pour le retour des signaux.
J'aurais pensé que les signal/slot est un pattern unidirectionnel qui permet à un « bout de code » de signaler 0, 1 ou plus d'autres fonctions. Il par rapport à l'appel direct de méthode, il permet un dispatch dynamique et par rapport aux callback, il permet principalement une simplification (le slot n'a pas à gérer ses clients) ce qui apporte un meilleur découplage.
Mais c'est ma vision probablement biaisée et ma lecture du pattern observable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll