Node.jsタイマーは非常に効率的に実装されています。それらの実装（それらがどのように機能するかについての詳細な記事で説明されています）は、非常に多数のタイマーを簡単に処理できます。
それらはソートされた二重リンクリストに保持され、次に起動するタイマーのみに実際のlibuvシステムタイマーが関連付けられます。そのタイマーが起動またはキャンセルされると、リスト内の次のタイマーが実際のlibuvシステムタイマーに接続されたタイマーになります。新しいタイマーが設定されると、それはソートされたリストに挿入され、次に起動するタイマーにならない限り、次の順番を待つだけでリストに配置されます。これらを非常に効率的に数千個持つことができます。
これらのタイマーの仕組みに関するリソースは次のとおりです。
パフォーマンスの問題が発生するまでの同時setTimeoutsはいくつですか？
nodejsはどのようにタイマーを内部的に管理しますか
最初のリファレンスには、タイマーリンクリストシステムがどのように機能し、何のために最適化されているかを説明する、実際のnodejsコードからの一連のコメントが含まれています。
2番目の記事では、その構成についてもう少し高いレベルで説明します。
他にも効率があり、1つのタイマーがリストの先頭に到達して起動すると、そのコールバックを呼び出した後、node.jsはリストの先頭で、起動の準備ができている他のタイマーをチェックします。これにより、最初のタイマーと同じ「目標時間」を持つ他のタイマーと、これらのさまざまな他のコールバックの実行中に期限が到来した他のタイマーが一掃されます。
数千の場合、タイマーがたくさんあると、並べ替えられたリンクリストに新しいタイマーを挿入するのに少し時間がかかりますが、一度挿入すると、見ているだけなので、いくつあるかはほとんど問題になりません。次に発射するもの。したがって、数万のタイマーが保留された状態でそこに座るプロセスは、1つのシステムタイマー（次に起動するタイマーイベントを表す）と大量のデータにすぎません。他の将来のタイマーのすべてのデータは、そこに座っているだけでは何の費用もかかりません。
Javascriptの場合、Pythonの最初のソリューションと同様に、必要な数のsetTimeoutsを生成できますが、問題はすべてのタイムアウトがメインスレッドで機能することですが、前述のように、タスクはリソースを大量に消費するものではなく、精度が必要なだけです。 2番目。
nodejsはあなたの量のsetTimeout()を処理できるように思えます うまく呼び出します。 node.jsで問題が発生した場合、タイマーの数が原因ではありませんが、1つのコアで処理できるよりも多くの処理が必要な場合は、問題に十分なCPUを適用する必要があります。 nodejsクラスタリング、またはワーカースレッドやその他のnodejsプロセスを使用して処理を支援するワークキューを使用して、コアの使用を拡張できます。 node.js自体は、CPUを大量に消費する主要な計算を行わない限り、I / Oに関連するあらゆるものに対して非常に効率的であり、単一のnode.jsスレッドで多くのイベント処理を処理できます。
Javascriptタイマーは正確性を保証しないことに注意してください。 CPUを停止すると、一部のタイマーはプリエンプティブではないため、スケジュールよりも遅く起動します。ただし、タスクにCPUを集中的に使用しない場合は、問題ない可能性があります。