目的
Livesplit の動作が重い場合に、Timer の表示桁数を 0.12 から 0.1 や 0 に変更することで、動作が軽くなるという意見を見かける。
その変更によって軽くなったという意見も見かけるため、動作が軽くなることは事実なのだろう。
では、その変更によってどのくらい軽くなるのか。それを数値的に表してみようと考え、今回の検証を行うことにした。
また、表示桁数を変更する他にも、Livesplit の重さに関係する項目がないかを確認する。
結論
Livesplit の CUP 使用率に対して、確かにタイマーの表示桁数が影響していると分かった。また、画面更新回数とレイアウトの影響の方がより大きいことも分かった。
つまり、Livesplit の CPU 使用率を低減したい場合は画面更新回数やレイアウトを変更することがより効果的である。
しかし、画面更新回数が一般的な更新回数(30 Hz や 60 Hz)よりも少ないと、Livesplit がカクついて見えて CPU 使用率に余裕がないとの誤解が生じ得る。
また、レイアウトに表示する項目は試行中に自分自身が確認したい情報であったり、配信・録画画面の見栄えや視聴者に対する情報表示でもある。
結局は、Livesplit の CPU 利用率を下げたい場面において、タイマーとしての機能と CPU 利用率とはトレードオフの関係であり、どの項目をどう設定するかは各々で考えるべき事柄である。
要は「Livesplit の CPU 使用率を低減したい場合、タイマーの表示桁数を減らすよりも画面更新回数やレイアウトを少なくした方が効果が高いけど、実際にどの項目を変えるかは Livesplit の使用目的に合わせて考えてね」ということです。
検証1
できるだけ CPU 使用率が大きくなるであろう条件を基準条件に設定する。
比較条件
基準条件を定め、基準条件に対して特定の項目のみを変更することで各比較条件とする。
基準条件
- Timer コンポーネントの表示桁数 1.23
- 画面更新回数 300 Hz
- 履歴件数 10,000 件
- レイアウト 多い、各表示桁数 1.23
各比較条件
( ) は基準条件
Timer コンポーネントの表示桁数
0, 1.2, (1.23)
Timer の表示桁数設定。実際の計測では Detail Timer を使用する。
Livesplit の重さに影響があるとよく言われている、小数点以下の表示に焦点を絞って確認する。
表示桁数の設定は3段階あるため、この検証でも3段階に対応した条件とする。
画面更新回数
20, 40, 60, 144, (300)
Settings の Refresh Rate。 Livessplit の標準値である 40 Hz、設定範囲の上限下限である 300 Hz と 20 Hz、ゲームやモニタの設定値としてあり得る 60 Hz と 144 Hz を条件とする。
画面更新回数はあくまで努力目標のような値であり、Livesplit の仕様として、実際に設定値の通りに更新されるわけではない。
また、私が所持しているモニタの限界が 60 Hz であり、それより高い更新回数に対応したモニタとで結果に差があるかもしれないことに注意。
履歴件数
0, 1, 100, (10,000)
Livesplit が読み込んでいる履歴データの件数。
履歴件数は試行を重ねるごとに増加するものであり、CPU 使用率を低減するために履歴件数を制限することは一般的ではないように思われる。
しかし、もしも履歴件数が CPU 使用率に影響を与えるのであれば、目安となるデータ件数を超えないようにデータ管理することができるのではないかと思い、検証の条件に加えた。
データ件数の有無を比較するために 0 件と 1 件、一般的に十分多い回数といえる 10,000 件、 1 件と 10,000 件の間の桁数として 100 件を条件とする。
10 区間、各 3s でラップを取ったデータをプログラムで出力して、lss ファイルとして読み込ませる。
計測の際に試行回数が+1されるので、例えば、履歴件数 100 件の場合であれば、CPU 使用率の計測中にタイマースタートした時が試行回数 101 になる。
レイアウト
Default, 多い 表示桁数 0, (多い 表示桁数 1.23)
レイアウトに追加する項目。
Livesplit に標準で付属しているコンポーネントで履歴データの集計を行うものを中心に選択し、タイムの桁数表示を 1.23 にしたものと 0 のもの、およびデフォルトのレイアウトを条件にする。
ただし、ここでの表示桁数設定には、Timer は含めない
計測ツール・計測条件
Windows標準のパフォーマンスモニタを使用する。
Win マーク右クリック → コンピューターの管理 で管理ツールを起動して、
システムツール → パフォーマンス → データコレクターセット → ユーザー定義 で新規作成
手動設定にて
Process → Processor Time にて Livesplit を選択して追加
サンプルの間隔は1秒
Excel でデータ処理をする都合により、データは csv で出力
計測環境
Windows 10 64bit
Intel Core i7-9700
16 GB
Livesplit 1.8.19
計測方法
各条件ごとに次の手順に従って、1分間の CPU 使用率を記録する。
- 比較条件にある条件の中から1つを選んで、Livesplit の設定を行う
- Livesplit をスタートしてから CPU 使用率の記録を開始する
- 記録開始から 60s 経過した時点で記録を停止し、Livesplit をリセットする
- 全ての条件で記録を取るまで繰り返す
計測誤差の影響を小さくするため半日以上の時間をおいてから、改めて全ての条件で記録を取、各条件とも合計4回の計測を行うまで繰り返す
結果
計測した CPU 使用率の時間変化のグラフ(各、4回計測した中の代表1つ)および、Livesplit スタート後の CPU 使用率の平均値を、各条件ごとに掲載する。
各条件とも、基準条件の計測値は共通のデータである。
CPU 使用率のグラフの縦軸は各 CPU コアの Livesplit の使用率を合計した値である。「CPU のコア数 * 100 %」が最大値で、検証を行った環境は8コアなので最大 800 % となる。
平均値を計算した表は、計測した CPU 使用率をコア数8で割った値である。
タイマーの表示桁数
タイマー表示桁数 | |||
---|---|---|---|
回数 | 1.23 | 1.2 | 0 |
1 | 9.1 | 8.1 | 7.6 |
2 | 9.9 | 9.3 | 9.0 |
3 | 10.1 | 8.6 | 7.8 |
4 | 6.7 | 7.1 | 7.2 |
表示桁数の多寡が CPU 使用率の大小に影響していると分かった。
「Timer の表示桁数を減らすことで動作が軽くなる」ことが、私の環境において確認できた。
画面更新回数
画面更新回数 | |||||
---|---|---|---|---|---|
回数 | 300 | 144 | 60 | 40 | 20 |
1 | 9.1 | 8.8 | 6.7 | 5.6 | 4.1 |
2 | 9.9 | 9.9 | 6.3 | 7.0 | 4.4 |
3 | 10.1 | 8.6 | 6.5 | 6.6 | 4.1 |
4 | 6.7 | 7.5 | 6.3 | 6.1 | 4.3 |
画面更新回数の多寡が CPU 使用率の大小に影響していると分かった。
画面更新回数の増加に対して CPU 使用率も増加傾向にあるが、グラフの形状が段階的な増加傾向にあるように見え、比例関係ではないように考えられる。
ただし、今回の検証では画面更新回数と CPU 使用率との関係についてはこれ以上は確認しないので、本当に段階的な増加なのかは不明である。
履歴件数
履歴件数 | ||||
---|---|---|---|---|
回数 | 10000 | 100 | 1 | 0 |
1 | 9.1 | 7.3 | 8.1 | 5.7 |
2 | 9.9 | 10.0 | 9.5 | 4.7 |
3 | 10.1 | 9.1 | 8.5 | 5.6 |
4 | 6.7 | 7.6 | 7.7 | 4.5 |
0 件とその他(1、100、10,000 件)とでの CPU 使用率の差を見ると、0 件だけは明らかに CPU 使用率が低い傾向にあることが分かった。
CPU 使用率の4回平均を見ると、件数の増加によって CPU 使用率も増加傾向にあるように見えるが、4回の内訳を見ると 10,000 件よりも 100 件、100 件よりも 1 件の方が CPU 使用率が高い場合もあった。
このため、0 件の時だけ明らかに CPU 使用率が低いが、1 件以上では履歴件数と CPU 使用率との間に明確な関係性は見られなかったと言える。
しかし、常に履歴件数 0 件の状態で Livesplit を使用するのは一般的ではないように思われる。この結果からは、1 件でも 10,000 件でも CPU 使用率に大きな違いはない、と考えた方が実用的である。
レイアウト
レイアウト | |||
---|---|---|---|
回数 | 多 1.23 | 多 0 | default |
1 | 9.1 | 6.2 | 3.7 |
2 | 9.9 | 6.3 | 4.9 |
3 | 10.1 | 6.3 | 3.7 |
4 | 6.7 | 5.4 | 3.3 |
条件ごとに CPU 使用率に明確な差が見られた。 レイアウトに含めるコンポーネントの数や設定内容によって CPU 使用率に影響があると言える。
検証1の結果まとめ
各条件ごとに4つある平均値からさらに平均値を取って、グラフにまとめた。このグラフの縦軸は計測値の平均をコア数で割った値である。
タイマーの表示桁数を減らすことで、確かに CPU の使用率が低減することを確認できた。
また、画面更新回数やレイアウトの条件を変更することでも CPU 使用率を低減することができた。減少量を見ると、桁数表示よりも画面更新回数やレイアウトを変更したほうがより効果的であると言える。
ここで2点、注意したい。
ひとつは、検証1はスペックに余裕のある環境で計測を行っており、Livesplit の動作が実際に重くなっている環境ではないという点である。
もうひとつは、画面更新回数 300 Hz、履歴件数 10,000 件と一般的な Livesplit の使用条件と比べて重たい条件を基準条件に設定しいるという点である。
スペックが低い環境を構築することができないため、スペックの余裕に関しては深く考えないものとする。
基準条件については、検証2として、より一般的な条件を基準条件に設定して計測を行うことにする。
検証2
検証1の条件よりも一般的な条件にて、検証1の結果と同様の傾向であることを確認する。
比較条件
基準条件
- Timer コンポーネントの表示桁数 1.23
- 画面更新回数 40 Hz
- 履歴件数 10,000 件
- レイアウト default
各比較条件
( ) は基準条件
Timer コンポーネントの表示桁数
0, 1.2, (1.23)
Timer の表示桁数設定。
画面更新回数
20, (40)
Settings の Refresh Rate
履歴件数
0, 1, (100)
Livesplit が読み込んでいる履歴データの件数。 10 区間、各 3s でラップを取ったデータをプログラムで出力して、lss ファイルとして読み込ませる。
計測ツール・計測条件
検証1と同様。
ただし、事情により各条件とも計測回数は1回とした。
結果
計測した CPU 使用率の時間変化のグラフおよび、Livesplit スタート後の CPU 使用率の平均値を、各条件ごとに掲載する。
タイマーの表示桁数
タイマー表示桁数 | ||
---|---|---|
回数 | 1.23 | 1.2 |
1 | 2.3 | 1.5 |
表示桁数の多寡が CPU 使用率の大小に影響している傾向にあることが見て取れる。
検証1と同じ傾向にあると判断した。
画面更新回数
画面更新回数 | |||
---|---|---|---|
回数 | 1.23 | 1.2 | |
回数 | 1 | 40 | 20 |
1 | 0.9 | 2.3 | 1.8 |
画面更新回数の多寡が CPU 使用率の大小に影響している傾向にあることが見て取れる。
検証1と同じ傾向にあると判断した。
履歴件数
履歴件数 | |||
---|---|---|---|
回数 | 1.23 | 1.2 | |
回数 | 100 | 1 | 0 |
1 | 2.3 | 2.4 | 1.5 |
検証1と同じ傾向にあると判断した。
検証2の結果まとめ
より一般的な条件にて計測を行った検証2においても、検証1と同様の傾向が見て取れた。
これにより、検証1の結果は、一般的な条件よりも厳しい条件であっても、一般的な条件であっても同じ傾向になると言える。
参考
パフォーマンスモニタについて
- パフォーマンスモニタでCPUリソース監視する際の主なカウンターについて『Rainbow Engine』
- windowsパフォーマンスモニタ『puti se note』
- CPUパフォーマンスについて『すえぞうのブログ』
0 件のコメント:
コメントを投稿