/* Page prose (ja) */
"CappingConcurrency" = "# 同時実行数を制限する\n\n基本のパターンは*すべて*のタスクを最初に追加します。8フレームならそれで問題ありません。500フレームでは、システムに500個の子を一度に開始するよう頼んだことになり、それぞれがデコード済みのフレームをメモリに抱えていたり、同じディスクやサーバーを叩き続けたりするかもしれません。それはメモリを破裂させ、ディスクを酷使し、あるいはレート制限を受ける原因になりえます。たいていは**並行数の制限**が欲しくなります。最大でも `N` フレームだけを実行中に保ち、1つが終わったときにだけ次を開始するのです。\n\nクラシックなモデルでは、これ用のネイティブなつまみがありました。[Operations](Operations.playgroundchapter/Overview) の章の `OperationQueue` の `maxConcurrentOperationCount` や、[グループとセマフォ](Groups%20and%20Semaphores.playgroundchapter/Overview) の章の `DispatchSemaphore` です。**task group にはそうした組み込みの設定はありません。** `group.maxConcurrency = 4` のようなものは存在しません。代わりに、*いつ `addTask` を呼ぶか*を制御することで上限を表現します。標準的なイディオムはこうです。グループに `N` 個のタスクを**呼び水として入れ**、そして集める側のループの中で、結果が1つ出てくるたびに新しいタスクを1つ追加します。それによって実行中の数は `N` あたりをうろつき続けます。";
"CappingConcurrency-2" = "**実行して確認:** 20フレームすべてがやはり処理され、結果はすべてを展開する版と同じです。しかし、どの瞬間にも4つを超えて実行されることはありません。20フレームを1つあたり0.5秒で4つずつのバッチにすると、全体で約**2.5秒**かかります。20個を一度に発射するよりは遅いですが、有界で予測可能なフットプリントを保てます。そのトレードオフ、つまりメモリと負荷に厳格な上限を課す代わりに少しの実時間を払うことこそ、これを使う理由そのものです。守りたいリソースに合わせて `maxInFlight` を調整してください。\n\n* callout(試してみよう): `maxInFlight` を `1` に設定してみましょう。グループをそのまま、逐次的な1つずつの版に戻したことになります。\n\n[前へ](@previous)  |  8 / 9 ページ  |  [次へ: まとめ](@next)";
