Les temporisateurs Node.js sont implémentés de manière très efficace. Leur implémentation (décrite dans un article détaillé sur leur fonctionnement) peut facilement gérer un très grand nombre de timers.
Ils sont conservés dans une liste à double lien qui est triée et seul le prochain temporisateur à déclencher est associé à un temporisateur système libuv réel. Lorsque cette minuterie se déclenche ou est annulée, la suivante dans la liste devient celle attachée à une minuterie système libuv réelle. Lorsqu'une nouvelle minuterie est définie, elle est simplement insérée dans la liste triée et, à moins qu'elle ne devienne la prochaine à se déclencher, elle reste simplement dans la liste en attendant son tour d'être la prochaine. Vous pouvez en avoir des milliers très efficacement.
Voici quelques ressources sur le fonctionnement de ces minuteurs :
Combien de setTimeouts simultanés avant les problèmes de performances ?
Comment nodejs gère-t-il les minuteurs en interne
La première référence contient un tas de commentaires du code nodejs réel qui décrit le fonctionnement du système de liste chaînée du minuteur et ce pour quoi il est optimisé.
Le deuxième article vous donne une description de niveau un peu plus élevé de la façon dont il est organisé.
Il existe d'autres efficacités pour que lorsqu'un minuteur arrive au début de la liste et qu'il se déclenche, puis après avoir appelé ce rappel, node.js vérifie le début de la liste pour tous les autres minuteurs qui sont maintenant prêts à se déclencher également. Cela balayera tous les autres minuteurs avec le même "temps cible" que le premier et également tous les autres qui sont arrivés à échéance pendant que ces divers autres rappels étaient en cours d'exécution.
Lorsque vous en avez des milliers, il faudra un peu plus de temps pour insérer une nouvelle minuterie dans la liste chaînée triée s'il y a beaucoup de minuteries, mais une fois qu'elle est insérée, peu importe combien il y en a car elle ne regarde jamais le prochain à tirer. Ainsi, le processus consistant à rester assis là avec même des dizaines de milliers de minuteries en attente n'est qu'une seule minuterie système (représentant le prochain événement de minuterie à déclencher) et un tas de données. Toutes ces données pour les autres minuteurs futurs ne vous coûtent rien juste en restant assis là.
Pour Javascript, similaire à la première solution de python, je pourrais générer autant de setTimeouts que nécessaire, mais le problème est que tous les délais d'attente fonctionnent sur le thread principal, mais comme je l'ai dit, les tâches ne nécessitent pas beaucoup de ressources et j'ai seulement besoin de précision pour le seconde.
Il me semble que nodejs pourrait gérer votre quantité de setTimeout() appelle très bien. Si vous aviez un problème dans node.js, ce ne serait pas à cause du nombre de temporisateurs, mais vous devriez être certain que vous appliquez suffisamment de CPU au problème si vous avez plus de travail à traiter qu'un seul cœur ne peut en gérer. Vous pouvez étendre l'utilisation du noyau avec le clustering nodejs ou avec une file d'attente de travail qui utilise des threads de travail ou d'autres processus nodejs pour faciliter le traitement. node.js est, en soi, très efficace avec tout ce qui concerne les E/S, donc tant que vous n'effectuez pas de calculs gourmands en temps processeur, un seul thread node.js peut gérer de nombreux traitements d'événements.
Gardez à l'esprit que les minuteurs Javascript ne garantissent pas l'exactitude. Si vous embourbez le processeur, certaines minuteries se déclencheront plus tard que prévu car elles ne sont pas préventives. Mais, si vos tâches ne sollicitent pas beaucoup le processeur, tout ira bien.
