Trop de threads tue le thread.

[germinolegrand]

Quand le module Audio est initialisé, il crée au moins 10 threads o_O !
Y-a-t-il une raison à cela ?

Dans le code je n'ai pas vu de launch en dehors des endroits où la musique est jouée (c'est d'ailleurs bien piquant le stop+launch dans le setPlayingOffset x) ).

D'autant que sur les 10 threads, 2 d'entre eux se suppriment et se relancent en permanence... ce qui n'est pas pour arranger les choses.

Est-ce OpenAL qui crée tous ces threads ?

[Laurent]

Aucune idée. Ca me paraît beaucoup. Après il y a peut-être le back-end audio bas niveau qui en crée aussi. Là il va falloir que tu te débrouilles pour trouver.

[Lolilolight]

Perso, le fait d'utiliser quelques thread sur une seule machine (3-4.) me bouffe déja trop de perfs hors que j'ai un intel i5 (un quad core.), alors 10 je n'imagine même pas ce que ça doit donner, il faudrait que je fasse des test avec std::thread ou d'autres librairies pour voir si ça consomme toujours autant..., si il y en a qui ont fait des tests se serait bien de se tenir au courant.
A moins que la SFML ou d'autres librairie que la SFML utilise, utilisent déja des threads pour certaines choses ?

[Laurent]

Perso, le fait d'utiliser quelques thread sur une seule machine (3-4.) me bouffe déja trop de perfs

Evite de tirer des conclusions générales de tes expériences, qui plus est sans test rigoureux pour les valider
4 threads à gérer c'est rien pour l'OS, c'est ce que tu fais dedans qui est lent. Donc ça ne sert à rien de dire "ça me bouffe trop de perfs". Changer de bibliothèque de threading n'y changera pas grand chose : une fois le thread lancé elle n'intervient plus, c'est uniquement ta fonction qui tourne, c'est donc elle seule qui est responsable des performances.

SFML utilise un thread par instance de sf::SoundStream (et dérivées) active. Quant à OpenAL, aucune idée mais il en utilise au moins un autre.

[Lolilolight]

Pourtant, mes fonctions ne sont pas trop gourmande..., elles ne font que de réceptionner les messages reçu par le client ou bien par le serveur et changer la tile courante pour les tiles animées.
Et hum une fois que un thread est lancé, il faut que l'os puisse bien gérer l'exécution de ces threads en parallèle, donc, il ne suffit pas qu'il soit lancé pour que ça marche, bref...
Je ne sais pas encore vraiment quelle fonction fait ralentir ainsi mon application, et je ne parviens pas à faire des tests sur les fonctions de la SFML et des librairies qu'utilise la SFML, le profiler ne me donne que des résultat pour mes propres fonctions, comment puis je arranger cela ?

[Laurent]

Et hum une fois que un thread est lancé, il faut que l'os puisse bien gérer l'exécution de ces threads en parallèle, donc, il ne suffit pas qu'il soit lancé pour que ça marche, bref...

Evidemment... Mais l'OS gère des centaines de threads en tout, entre les threads du noyau, les services, et toutes les applications qui tournent en parallèle. Donc c'est pas tes 4 threads supplémentaires qui vont y changer quelque chose. Et puis le temps pris par l'ordonnanceur pour gérer les threads et changer le contexte d'exécution, c'est la base de l'OS, c'est donc ultra rapide. Evidemment, si tu commences à créer 1000 threads dans ton appli, là tu vas avoir des soucis... mais pas 4

Je ne sais pas encore vraiment quelle fonction fait ralentir ainsi mon application, et je ne parviens pas à faire des tests sur les fonctions de la SFML et des librairies qu'utilise la SFML, le profiler ne me donne que des résultat pour mes propres fonctions, comment puis je arranger cela ?

Fais des tests sur des sous-ensembles plus petits. Défriche. Faire des tests sur une grosse application ça ne mène à rien.

[Lolilolight]

C'est bon j'ai trouvé le problème.

[germinolegrand]

Je ferai des investigations, pas trop le choix de toute façon.
Ce sont surtout les threads qui se lancent et s'arrêtent en permanence qui m'intriguent (et surtout risquent d'avoir un mauvais impact sur les perfs).

(Désolé pour le temps de réponse, oublié de cocher notif par email)

[domoi]

Utilises tu des futures / promises dans ton code a un moment donnée ? (ajout de C++11)

[Eroy]

std::thread n'est implanté que partiellement et les futures ne sont donc pas utilisables, en tout cas avec notre compilo. Donc non il n'utilise ni l'un ni l'autre mais on les attends avec impatience. ^^