パフォーマンス問題の診断

まず最初に: time-usage を開く

Factorio の工場が大きくなると、 必ずぶつかるのが UPS 低下です。
大規模工場プレイヤーが何よりも気にする数値で、 60 を切ると目に見えてゲームが遅くなります。
ロケット 1 機ぶんを打ち上げる程度の規模なら気にする必要はありませんが、 メガベースに向かう人はこの調査手順を覚えておく必要があります。

時間使用 (time-usage) 画面を開いてください。
継続的に UPS が低いなら 「最初の」 列の大きな数値を、 断続的なスタッターやフリーズがあるなら 「三番目」 の列の大きな数値を探します。
これが鉄則。
平均か最大か、 見るべき列を間違えると犯人が見えません。

F4 でデバッグメニュー

F4 キーを押して Debug settings メニューを開きます。
ここにさまざまなオプションが表示されます。
次の 3 つを有効にしてください。

• show-fps: 画面の右上に FPS と UPS のカウンターを表示
• show-time-usage: ゲームの各システムがパフォーマンスにどれだけ影響しているかの詳細を表示
• hide-mod-guis: MOD のウィンドウやボタンが show-time-usage の表示を隠すことがあるので、 邪魔を取り除く

ヒントとして、 数字を読みやすくするためにマップを開いて未探索の領域にスクロールすると、 情報が黒い背景に表示されて視認性が上がります。
ちなみに、 デバッグオプションやデバッグ設定メニューの詳細については Debug mode を参照してください。

FPS と UPS の違い

最初に見るべきは右上の FPS/UPS カウンターです。
ここで全体像を把握します。

FPS とは

FPS は Frames Per Second (毎秒フレーム数) で、 画面に絵を表示するためにグラフィックカードが行う処理に関係します。
FPS が低いと画面の更新頻度が下がりますが、 ゲーム自体の速度は通常通り進みます。
「カクついて見えるが、 工場の処理速度は変わっていない」 状態と言えばわかりやすい。

UPS とは

UPS は Updates Per Second (毎秒アップデート回数) で、 ワールドの状態を進めるための計算に関係します。
UPS が低いとゲームはスローモーションで進みます。
Factorio は常に 60 FPS と 60 UPS を目指しています。
大規模工場で UPS が落ちると、 ベルトが目に見えて遅くなり、 採掘も遅くなり、 ゲーム全体が間延びします。

関係性: FPS は UPS を超えない

FPS は UPS を超えることはできません。
ここから 2 つの場合が考えられます。

• 低 FPS、 高 UPS: 問題はグラフィック側。
  Factorio のグラフィック設定を調整してください。
  グラフィックカードのアップグレードが効果的
• 低 FPS、 低 UPS: 問題は UPS の低下。
  原因の特定と UPS 節約の方法を見つけるため、 このチュートリアルの続きを読み進めてください

実プレイで多いのは後者で、 工場拡張のしすぎで UPS が落ちているパターン。
GPU よりも CPU の方がボトルネックになりやすいゲームです。

time-usage 画面の読み解き方

表示の仕組み

時間使用画面には、 テキストと数字の塊が表示されます。
各行は次の形式です。

システム名: 平均 ms / 最小 ms / 最大 ms

これらの数字はすべて 「ミリ秒/ティック」 です。
ティックは 1 回の更新ステップで、 UPS にとっての 「フレーム」 が FPS に相当するのと同じ位置付け。
Factorio は 1 秒間に 60 ティックを目指しているため、 各ティックの計算に 16.667 ms の時間が割り当てられています。
これを超えると UPS は 60 を下回ります。

3 つの数値の意味

各行の 3 つの数値は、 そのシステムが直近 100 ティックで取った平均時間、 最小時間、 最大時間です。
平均が高ければ持続的な負荷、 最大だけが突出していれば断続的なフリーズの犯人候補です。

集計範囲を広げる

この情報は直近 100 ティック、 すなわち約 2 秒未満のプレイ時間についてのみを示しています。
パフォーマンス問題が断続的に発生する、 あるいは特定の操作をしたときだけ発生する場合は、 その間に画面を表示しておく必要があります。
もし発生が速すぎるならスクリーンショットを撮って後で読むこともできます。
/perf-avg-frames 1000 コマンドを使えば、 考慮するティック数を 1000 (または別の数) に増やせて、 100 ティック単位で揺れる瞬間ノイズの影響を受けずに長期トレンドを見られるようになるので、 大規模工場で「平均は 50 UPS なのに体感ではもっと遅い」 みたいな揺らぎを掴むのに有効です。
メガベース勢はこの値を 1000-3000 にしている人が多いです。

大きな数値を探す

情報の意味がわかったら、 大きな数値 を探してください。
継続的に UPS 問題がある場合は 平均時間 を見ます。
断続的なフリーズや大きなスタッターがある場合は 最大時間 を見ます。

60 UPS は 1 ティックあたり 16.667 ms に相当するので、 おおよそ 1 ms は約 3.5 UPS のコストだと考えられます。
1 ms を超える項目は調べる価値があり、 5 ms を超えるものは非常に重要。

主要な行の意味

疑わしい大きな数値を見つけたら、 以下の表を参照してその行が何を意味するか、 気にすべきかどうか、 そしてどう対処できるかを確認してください。

項目	説明	対処
Last save	最後のセーブにかかった時間。 UPS とは無関係	-
Frame cycle	フレーム描画の総時間。 16.667ms 未満になることはない、 UPS カウンタ以上の情報は得られない	-
Wait For Update	GPU がワールド更新を待った時間。 下の Update 行とほぼ同じになるはず	-
Render preparation	フレーム描画関連の CPU 処理。 ズームアウトや工場の混雑エリアで増える	-
Render	フレーム描画関連の GPU 処理。 ズームアウトや混雑エリアで増える	-
Flip[On/Off]	グラフィックドライバ待ち時間。 [] 内は Vsync の有無	Vsync を切り替えてみる
Sleep	1 ティックが 16.667 ms 未満で完了した時の待機時間。 これが 0 超えていれば 60 UPS	-
Update	ワールドティック処理の総時間。 ほとんどの場合ここが支配的	サブ行で詳細確認
Game update	コアシステムの時間	サブ行で詳細確認
Circuit networks	回路ネットワークの計算	コンビネータと回路接続を減らす
Transport lines	ベルト関連	ベルト UPS 最適化は別途研究領域、 ここでは省略
Fluid manager	流体システム	パイプ数を減らす、 地下パイプで 3 本以上のパイプを置き換える
Heat manager	熱システム	熱エンティティを減らす、 原子力 → ソーラーへの置換
Entity manager	各種エンティティ全般、 多くの場合最大値	次節の entity time usage で深掘り
Electric networks	電力ネットワーク数 (サイズではなく数)	孤立した電柱を減らす、 1 本だけの電柱もコスト
Trains	列車	少数・大型化、 UPS 最適化の鉄道網設計
Chart update	レーダーによるマップ更新	レーダー数を減らす
Lua garbage incremental	MOD スクリプトのガーベジコレクション	Script update を先に確認
Script update	MOD の Lua スクリプト実行時間	重い MOD を特定して削除

(注: 上の表は元の英語表をそのままの構成で保持しつつ、 各セル内の説明を翻訳しています。
)

隠れた MOD のコスト

Script update セクションに表示される MOD の行が、 その MOD のコスト全体を表しているとは限りません。
MOD はコアシステムの時間に間接的に影響を与えることがあります。
たとえば、 列車を頻繁に再経路させる MOD は Trains のコストを増やす可能性があり、 多数の異なる電力ネットワークを作成する MOD は Electric networks のコストを増やします。
「Script update は軽いのに、 MOD を切ると UPS が回復する」 という現象はこの間接効果が原因で、 自前で書いた MOD ではなく外部 MOD を疑う時にも、 単純に Script update の値だけを見て判断すると本当の犯人を見逃すことが多いので、 1 つずつ MOD を切って差分を比較する古典的な切り分けが結局いちばん確実です。

entity time usage 画面

切り替え方

再度 Debug settings メニューに戻り、 show-entity-time-usage を有効にし、 show-time-usage を無効にしてください (表示が邪魔になるため)。

表示の見方

この画面では、 前の画面での Entity manager コストが各エンティティクラスごとに分割されて表示されます。
各行の最初の数値はそのティックでの時間コスト、 二番目の数値はそのクラスのアクティブなエンティティ数です。

ほとんどの行は説明不要ですが、 いくつか注記。

AssemblingMachine

組立機だけでなく、 レシピを選択する必要があるすべての建物 (化学プラント、 精錬所など、 ただし炉は除く) が含まれます。
このコストに関しては機械の数が重要で、 速度ではありません。
ビーカーやモジュールで少数の高速な機械にする方が、 多数の遅い機械よりもコストは低くなります。
これは大規模工場の最適化で見落とされやすいポイントで、 「とりあえず組立機 1 を並べる」 戦法は UPS 観点では最悪、 同じ生産量を組立機 3 + 速度モジュール + ビーコンで実現すれば機械数を 5-10 倍減らせるので、 メガベース勢が中盤以降に必ず通る道です。

Inserter

インサーターの数を減らし、 動作頻度を下げます。
たとえば 「inserter clocking」 (回路で必要な時だけ動かす) を使うなど。
メガベース勢はインサーター数の削減だけで数 % の UPS を取り戻したりします。

Unit

ビターやスピッター (敵ユニット) です。
これらを排除すればこのコストは減ります。
マップ生成時に敵を無効にしている人はここがゼロのはず。
敵込みで巨大工場を回すと、 進化ファクターが上がるにつれて Unit のコストが指数的に膨らみます。

Belt

トランスポートベルトはエンティティ数というよりレーン上のアイテム数で重くなります。
アイテムが流れていない停滞ベルトは比較的軽く、 高速で大量に流れているフルベルトが重い。
直感に反するが、 サブ工場の入口でアイテムが詰まっている方が UPS には優しい、 という逆転現象が起きます。
これに気付かずに 「ベルトを増やせば UPS が回復するはず」 と勘違いして、 高速ベルトを大量に敷設してかえって UPS を悪化させるパターンは大規模化の初期段階で頻発します。

最適化を尽くしたら

このセクションで最適化できる項目を使い尽くしたら、 あなたの工場は PC の処理能力を超えるほど大きくなっている、 ということです。
おめでとうございます。
これより先の最適化はメガベース勢の領域で、 ベルト UPS の dark art (ベルト統合戦略)、 鉄道網の UPS 設計など、 専門的な世界に入っていきます。

メガベース向けの追加 Tips

ここから先はメガベース勢の世界で、 一般プレイヤーは読み流して構いません。

電力ネットワーク数の罠

孤立した電柱 1 本でも、 1 つの電力ネットワークとしてカウントされます。
ブループリントを大量に貼り付けると、 接続されていない電柱がポツポツ残ることがあり、 これが Electric networks のコストを地味に押し上げています。
定期的に map をスキャンして孤立電柱を掃除すると、 数十 ネットワーク分の UPS が浮きます。

Fluid 最適化

パイプ網を最適化するなら、 地下パイプを最大限活用するのが定石です。
地下パイプ 1 セットは 2 つの流体エンティティとしてカウントされますが、 同じ距離を地上パイプで埋めれば 5 本以上必要になり、 結果として軽くなります。
ちなみに、 原子力プラントの蒸気配管はここが特に重く、 ソーラー + アキュムレータに切り替えると Fluid manager と Heat manager の両方が消えます。

Train ネットワークの最適化

列車は少数を大型化するのが UPS 観点で有利です。
同じ輸送量なら 4-4 列車 5 編成より、 2-8 列車 1 編成の方が軽い。
ただし駅設計はやや複雑になるので、 序盤からこれを狙う必要はありません。
工場が 100 列車を超えるあたりから検討開始、 が現実的なライン。

MOD の見極め

MOD が原因で UPS が落ちている場合、 show-lua-object-statistics デバッグオプションが役に立つことがあります。
Lua オブジェクトを大量に生成 / 破棄している MOD を特定できます。
期待より性能が悪い場合、 MOD 作者に bug 報告するという選択肢もあります。