ピン留めされたアイテム

やり方の基本

できるならビルド時最適化を試してみる
アプリ全体でプロファイルする
プロファイルでネックが見つかったら細かく比較計測
Peanut Butterよりアルゴリズム見直し・並列処理化・非同期化・遅延実行

注意点

ネック箇所の比較計測には BenchmarkDotNet を使う
- 事実上標準
- System.Diagnostics.Stopwatchは辞める
  - 理由
  - めちゃくちゃ時間かかる処理とかはあり
    - StopWatch.GetElapsedTime() (.NET7+
ランタイム/コンパイラの違いを意識する
- 新しい.NETほど同じソースでも高速
  - たとえば、一部のforeachがforに事前展開されたりしている
- SharpLab で展開後のコードやILの違いを確認できる
- Unityのランタイムは標準と違うので注意
  - ちょっと古い手法が有効
.NET 8.0以降は計測時に Dynamic PGO のON/OFFに注意
- 良くないコードも Dynamic PGOが効くと最適化されて速くなるから
新しい情報収集を忘れずに
- 昔はよかったものももっといい手法・アルゴリズム・ライブラリが出てきたりする
- 内部実装が変わって速くなることがある
- 例
  - 変化の大きいC#の文字列の最適化手法

どのやり方をつかう？

重い処理が…

どんな時も

アルゴリズムの見直し
- 1000倍早くなることもよくある

ネットやファイル読み込みが重い

非同期処理 (async / await）
アルゴリズムの見直し
- 一度に全部呼び出さない・読み込まない

CPUが重い

一瞬だけ重い
- 遅延実行（ LINQ / Lazy<T>)
いつでも重い
- 並列処理
  - TPL : ParallelFor とか
  - PLINQ : AsParallel()で使える並列LINQ
  - Concurrent Collection : 並列処理用コレクション
  - Synchronization Primitives（同期プリミティブ）：semaphoreSlimとかSpinLockとか
  - パーティショナー：TPL/PLINQ用にデータを分割
- SIMD命令
  - https://learn.microsoft.com/ja-jp/dotnet/standard/simd
- GPUに任せる
  - ComputeSharp
  - Silk.NET (OpenCV)
  - ML.NET
  - OpenTK

いぬいぬ 4ヶ月前

調べ方：用語

最適化
高速化
optimize / optimization
performance
peanut butter

いぬいぬ 24日前に更新

情報源

いぬいぬ 3ヶ月前に更新

ビルド時最適化

そもそもコード中で頑張らなくてもビルド設定でも最適化できる
- まず最初に見直す
中間コードJITコンパイルのメリットを捨てて最適化する方法、だったり
- メリットとデメリットの比較が大事！
.NETなのでC#以外でも有効

【前提】最新の.NETむけに最新の.NETでビルドする

新しい.NET SDKでコンパイルするとより最適化されたコードが出力される
新しい.NET ランタイムで実行するとより高速な処理になる（SIMD/Dynamic PGOとか）

R2R (Ready To Run)

事前コンパイルで起動が早くなる
- この意味ではC#は正確にはJITではなかった
結構前から使える
- 最新の技術じゃないので使えることが多い
ファイルサイズがデカくなる
- …けど今なら別にいいんじゃないかなぁ
事前コンパイルなのでプラットホーム依存

<PropertyGroup>
  <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

NativeAOT

ネイティブバイナリへの事前コンパイル
- PublishTrimがデフォでされるらしく容量も小さめになる
.NET 7.0以降が公式サポート
制限がそこそこある
- リフレクションとかと相性悪い
  - そりゃそう
- .NET7だとGUIに対応してない[ウソ]
  - これはMAUIとかの話。Avaloniaでいいじゃん。
- モバイル系は.NET 8でも実験的サポート
事前コンパイルなのでプラットホーム依存
クロスコンパイルできない
- まあそりゃそう
  - 中間コードのメリットを捨てて最適化する方法だしね
- x64 - arm64はできることもあるっぽい

OptimizationPreference

サイズと速度どちら優先かを選べる

<OptimizationPreference>Size</OptimizationPreference>
<OptimizationPreference>Speed</OptimizationPreference>

IlcInstructionSet / IlcMaxVectorTBitWidth

追加のCPU限定命令を有効に出来るオプションがある
- Optimizing programs targeting Native AOT

.NET 8.0 >=

<PropertyGroup>
  <IlcInstructionSet>native</IlcInstructionSet>
  <IlcMaxVectorTBitWidth>512</IlcMaxVectorTBitWidth>
</PropertyGroup>

Dynamic PGO

.NET 8.0以降そのままで有効
.NET 7.0

<PropertyGroup>
    <TieredPGO>true</TieredPGO>
</PropertyGroup>

いぬいぬ 4ヶ月前に更新

変化の大きいC#の文字列の最適化手法

前提：C#の文字列`string`はネックになりがち

C#のstringはimmutable
書き換えは新しい文字列が作られる
新しく作られる→ヒープメモリ確保→メモリアロケーション→GCが走りやすくなる
…でネックになりやすいらしい

文字列最適化手法の変化

古い情報だと「とりあえずStringBuilder」というものが多いけど、最近は色々最適化されるようになってきていて昔の方法が通じないかんじ。

昔：
- 「文字列結合は+を使わずStringBuilderで！」
.NET 8時代 ：
- ある程度固定されてる文字列なら文字列補完を使う $"abc{val}"
- StringBuilderより文字列補完の中で使われてるDefaultInterpolatedStringHandlerの方が速くなる
- 文字列がUTF-8なら（C#内部はUTF-16)、UTF8文字列リテラル("あいう"u8)で扱う
  - ReadOnlySpan<byte>として扱われる

https://gitan.dev/?p=320

.NET8時代の考え方

大半は 生文字列リテラル と 文字列補完 でOK
- C#は新しい書き方が「速くて便利」になるようにしているらしい
- 文字列の加工が必要な場面って大半がテンプレ的な文字列だったり

C# 11.0以降

var yatta = "やったぜ！";
var str = $"""
  改行OK! ({yatta})
  文字列エスケープ不要！ ({yatta})
  インデントしてもOK！ ({yatta})
  """;

なるべくstringのままで扱わない
- 最初と最後だけにする
  - ToString()しない
  - 可能ならそれすらも避ける
- (型のサイズ的な意味で)1文字ならchar
- もっと最適化するならbyte / Span<byte>で扱う
  - ReadOnlySpan<byte>で文字列
  - UTF-8文字列リテラル →参考「C#12.0 .NET8.0における、Utf8文字列の作り方とパフォーマンス – 技探」

`String.Intern` はそのままだと自作キャッシュに負けるがNativeAOTで逆転

いぬいぬ 4ヶ月前に更新

.NET 8.0の高速化用新機能・ライブラリ

System.Collections.Frozen
- 「コレクションの作成後にキーと値を変更することができません。この要件により、読み取り操作を高速化できます」
- nugetで導入できる
System.Buffers.SearchValues
- 【C#】SearchValues<char> を測ったら桁違いに速かった - てくメモ
- 前のバージョン向けには公開されてない…
System.Text.CompositeFormat
- 「コンパイル時に不明な書式指定文字列を最適化する場合に便利」
- 前のバージョン向けには公開されてない…
System.IO.Hashing.XxHash3 / System.IO.Hashing.XxHash128
- 高速ハッシュ生成
- nugetで導入化
System.Runtime.Intrinsics.Vector512<T>
- AVX-512(SIMD)
- 前のバージョン向けには公開されてない…
Parallel.ForAsync
- Parallel.For の非同期版
- ForEachAsyncは前からあった
  - ForEachAsync より4倍速くメモリアロケーションも少ない例が公式にある
- 前のバージョン向けに公開されてないっぽい

いぬいぬ 4ヶ月前に更新

決して最速じゃない配列`T[]`

C#の配列T[]は利便性なら List<T>, パフォーマンスなら Span<T>に負ける（ことがある）
- .NET 8.0時代だと、なんでもかんでも配列化、はNG

C#の配列はプリミティブなものだから速い、というわけでもない
- 要素の追加削除で再割り当て
- コピーが発生（メモリアロケーション）
- .NETの内部ではT[] -> Span<T>への置き換えが進んでいて高速化が図られている

バッファで使うならnew byte[]じゃなくて
- サイズが小さいならstackalloc byte[]でSpan<T>/ReadOnlySpan<T>で扱う
- 大きいorわからないなら ArrayPool<T>.Shared.Rent()

いぬいぬ 4ヶ月前

TaskとValueTask, TupleとValueTuple

Valueがついてる方が構造体
- パフォーマンスを意識した実装

TaskとValueTask

Task<T>の方が古い
- クラスなのでムダが…
- awaitしないで抜ける時とか割とよくある
ValueTask<T>
- 理由がなければこれで

TupleとValueTuple

ValueTupleは直接使うことない
- タプル記法の中身がこれ
Tuple型はクラスでメモリアロケーション
- まあつかわないかな（匿名型も）

いぬいぬ 24日前に更新

インライン化阻害防止

反復・例外処理をprivate/local関数化

C# コンパイル結果の IL 命令が32バイトを超える場合、インライン化しない
反復処理を含む場合、インライン化しない
例外処理を含む場合、インライン化しない

ので

反復（forとか）や例外のところだけstaticな（privateやローカル）関数で外に出すとインライン化されやすくなる。

インライン化属性

[MethodImpl(MethodImplOptions.AggressiveInlining)]を付与すると、サイズが小さければインライン化してくれる（こともある）。

インライン化防止属性（[MethodImpl(MethodImplOptions.NoInlining)]）はベンチマーク取る時に大事。

インライン化すれば必ず早くなるわけじゃないのに注意。
DynamicPGOはその辺動的に判断するらしい。

例外処理用属性

DoesNotReturn
DoesNotReturnIf

PolySharpで古い環境にも入れられる

`ThrowHelper`/ スローヘルパー系

System.ThrowHelper

dotnet内部で使われてる
internal :cry:
コードサイズ削減が目的

`ThrowIf～`系

.NET には、特定の条件 (ArgumentNullException.ThrowIfNull と ArgumentException.ThrowIfNullOrEmpty) で例外をスローするヘルパーメソッドも用意されています。

一部はExceptionクラスのメソッドとして利用できる

.NET Standard 1.0
- CancellationToken.ThrowIfCancellationRequested
.NET 7.0
- ArgumentNullException.ThrowIfNull
  - CA1510: ArgumentNullException スローヘルパーを使用する - .NET | Microsoft Learn
- ObjectDisposedException.ThrowIf
.NET 8.0
- ArgumentException.ThrowIfNullOrEmpty
- ArgumentException.ThrowIfNullOrWhiteSpace
- ArgumentOutOfRangeException
  - ThrowIfEqual
  - ThrowIfGreaterThan
  - ThrowIfGreaterThanOrEqual
  - ThrowIfLessThan
  - ThrowIfLessThanOrEqual
  - ThrowIfNegative
  - ThrowIfNegativeOrZero
  - ThrowIfNotEqual
  - ThrowIfZero

Microsoft.Toolkit.Diagnostics.ThrowHelper

.NET Community Toolkit に例外を外部関数化したThrowHelperがライブラリ化されている.
コードサイズも小さくなる。
Guard APIも

Guard / ガード系

いわゆる「ガード句」用のライブラリも同じ用途で使える。

CommunityToolkit.Diagnostics.Guard

public static void SampleMethod(int[] array, int index, Span<int> span, string text)
{
    Guard.IsNotNull(array);
    Guard.HasSizeGreaterThanOrEqualTo(array, 10);
    Guard.IsInRangeFor(index, array);
    Guard.HasSizeLessThanOrEqualTo(array, span);
    Guard.IsNotNullOrEmpty(text);
}

いぬいぬ 1ヶ月前に更新

LINQは遅い？

「決して最速じゃない配列T[]」で書いたようにfor文でT[]を色々するよりLINQが早い場合もある。

新しい.NETを使う

SIMD化などで高速化するものがある
- .NET 7.0
  - int/longのMin() / Max()
- .NET 8.0
  - int/long以外のMin() / Max()
  - Sum()
  - Order() / OrderDescending()
  - keyが値型の時の OrderBy() / OrderByDescending()
  - new Dictionary<K, V>(List<KeyValuePair<K, V>>)

PLINQで並列処理する

データ量がある程度多いならforで回すよりPLINQで並列化のほうが効果的
- Parallel.For とかでもいいけど…

LINQ高速化ライブラリを使う

SimdLinq
- SimdLinq - LINQをそのままSIMD対応して超高速化するライブラリ
- .NET 7.0～
BurstLinq
- 【Unity】BurstLinq – Burst Compilerを用いたLINQ高速化ライブラリ
- Unity
NetFabric.Hyperlinq
- support for Span<T>, ReadOnlySpan<T>, Memory<T> and ReadOnlyMemory<T>

間違った使い方をしない

Enumerableで長さを確認するのにAny()を使わない
- Length/Count/IsEmptyプロパティを使う
- いつもAny()つかうな、ではないのに注意。Count()の代わりに推奨されるときも。
- CA1860: 'Enumerable.Any()' 拡張メソッドを使用しない
- アナライザーが教えてくれる

LINQ 高速化ライブラリ比較

.NET8.0ではちょくちょく素のLINQが最速というパターンがある
単純なfor/foreachより早いケースも

いぬいぬ 4ヶ月前に更新

プロファイル

ベンチマーク

BenchmarkDotNet

Home | BenchmarkDotNet
- 事実上の標準
- BenchmarkDotNet templates
  - dotnet new benchmarkでテンプレ導入できる
benchly
- https://github.com/bitfaster/benchly
- グラフ出力
VBench
- GitHub - Ackara/VBench: An graphical HTML exporter for BenchmarkDotNet.
- リッチなグラフ出力
BenchmarkDotNet Analyser (BDNA)
- https://github.com/NewDayTechnology/benchmarkdotnet.analyser
- Measuring performance using BenchmarkDotNet - Part 3 Breaking Builds

benchmark.net使用時注意

複数ランタイムで比較する
- .NET Frameworkと.NETの最新LTS、最新とか
- 内部処理が違うので同じコードでも差がでる
- 可能ならR2R・NativeAOTも比較
  - 最新版だけでいいかも
インライン化を抑制する
- 純粋な処理の差を見るため
- [MethodImpl(MethodImplOptions.NoInlining)]
Dynamic PGOを抑制する
- 純粋な処理の差を見るため
- .NET 8.0～

アプリprofiler

dotnet-counters
- 公式無料
- dotnet-counters 診断ツール - .NET CLI - .NET | Microsoft Learn
dotnet-trace
- 公式無料
  - dotnet-countersより詳細
  - Chromeのプロファイラやspeedscopeで可視化できる
- .NETのパフォーマンス計測ツール「dotnet-trace」の使い方 | Technology | KLablog | KLab株式会社
- dotnet-trace 診断ツール - .NET CLI - .NET | Microsoft Learn
Intel VTune
AMD uProf
- AMD CPUのみ
- AMD μProf | AMD
PerfCollect
- Linuxのみ
- PerfCollect を使用した .NET アプリケーションのトレース。 - .NET | Microsoft Learn
dotTrace
- 有料
- JetBrains

いぬいぬ 4ヶ月前に更新

ローカルstaticフィールドは`ReadOnlySpan<T>`＋コレクション式でできる

void DoSomething(){
   //できない
   //static int[] arr = {1,2,3};
   
   //staticと同じ扱い
   ReadOnlySpan<int> arr = [1,2,3];
}

ローカルなReadOnlySpan<T>変数をコレクション式で宣言するとstaticと同等になる
読み取りが高速化
- メモリは減らない
sharplabで調べたら本当だった
- 現時点だと__StaticArrayInitTypeSize=12_Align=4っていう自動生成されたクラス内のstaticな構造体になってる

いぬいぬ 4ヶ月前

[Peanut Butter]`Span<T>`のコピーで長さの判定を入れると速くなる（.NET8）

if(spanA.Length == 10){
  spanA.CopyTo(spanB);
}else{
  spanA.CopyTo(spanB);
}

PRが通ってるので.NET 9.0では自動で内部的にこれになりそう。

いぬいぬ 3ヶ月前に更新

newしない初期値・リセット

初期化・リセットのたびにnewすると遅い
代わりに空を示すプロパティ・メソッドが用意されてる
わかりやすくなるメリットも

文字列 `string.Empty`

""の代わり
現状だとパフォーマンス面であんまり差はないかも？
- わかりやすさは上

配列 `Array.Empty<T>()`

メモリアロケーション防止

コレクション `Enumerable.Empty<T>()`

メモリアロケーション防止
.NET8時点ではEmptyPartition<T>.Instanceっていうキャッシュされたゼロenumberableが返ってくるっぽい

リスト `ImmutableArray<T>.Empty`

List<T>.Emptyはない
けど、ImmutableArray<T>.Emptyならある

ReadOnlyCollectionにもある
- .NET8以降

FrozenSet / FrozenDictionaryにもある

Span<T> `Span<T>.Empty`

Span<T>, ReadOnlySpan<T>, Memory<T>, ReadOnlyMemory<T>にある

コレクション式で初期化 `[]`

.NET8.0時点では、ケースバイケース。

T[]
- Array.Empty<T>()が呼ばれる 👍
List<T>
- new List<T>()と同じ
ImmutableArray<T>
- ImmutableCollectionsMarshal.AsImmutableArray(Array.Empty<T>())が呼ばれる
Span<T>
- default(Span<T>)と同じ
string
- 使用不可
UTF-8 string
- default(ReadOnlySpan<byte>)と同じ

int[] array = [];  //Array.Empty<int>();
List<int> list = []; //new List<int>();
ImmutableArray<int> im = []; //ImmutableCollectionsMarshal.AsImmutableArray(Array.Empty<int>());
Span<int> span = []; //default(Span<int>);
//string str = [];  //error!
ReadOnlySpan<byte> u8str = []; //default(ReadOnlySpan<byte>);

いぬいぬ 1ヶ月前に更新

半公式の高速化ライブラリ

.NET Community Toolkit

コミュニティベースのライブラリだが、MSが開発していてMS Learnにリファレンスがある
以下がパフォーマンスに影響
- CommunityToolkit.Diagnostics
  - ThrowHelper
  - Guard API
  - →インライン化阻害防止
- CommunityToolkit.HighPerformance
  - Span2D<T> / Memory2D<T>
  - MemoryOwner<T> / SpanOwner<T>
  - StringPool
  - ParallelHelper

.NEXT

.NEXT (dotNext) is the family of powerful libraries aimed to improve development productivity and extend the .NET API with unique features. The project is supported by the .NET Foundation.

dotnet公式リポジトリで管理されている

Microsoft.IO.RecyclableMemoryStream

System.IO.MemoryStreamに特化したプーリングライブラリ

いぬいぬ 1ヶ月前

実行時最適化

Tiered Compilation

P18

速度優先（QuickJIT, Tier 0）と最適化優先(Tier 1)に"実行時に"処理が分かれる
- .NET Core 3.0以降
csproj or runtimeconfig.json or 環境変数で設定変更可能
R2RでビルドするとTier1に

<TieredCompilation>false</TieredCompilation>
<TieredCompilationQuickJit>false</TieredCompilationQuickJit>
<TieredCompilationQuickJitForLoops>true</TieredCompilationQuickJitForLoops>

On-Stack Replacement

情報

.NET 8 で既定で有効になった Dynamic PGO について - Speaker Deck
.NET の最適化の罠? (インライン展開がされなかった理由) #C# - Qiita

やり方の基本

注意点

どのやり方をつかう？

どんな時も

ネットやファイル読み込みが重い

CPUが重い

調べ方：用語

情報源

ビルド時最適化

【前提】最新の.NETむけに最新の.NETでビルドする

R2R (Ready To Run)

NativeAOT

OptimizationPreference

IlcInstructionSet / IlcMaxVectorTBitWidth

Dynamic PGO

変化の大きいC#の文字列の最適化手法

前提：C#の文字列stringはネックになりがち

文字列最適化手法の変化

.NET8時代の考え方

String.Intern はそのままだと自作キャッシュに負けるがNativeAOTで逆転

.NET 8.0の高速化用新機能・ライブラリ

決して最速じゃない配列T[]

TaskとValueTask, TupleとValueTuple

TaskとValueTask

TupleとValueTuple

インライン化阻害防止

反復・例外処理をprivate/local関数化

インライン化属性

例外処理用属性

ThrowHelper/ スローヘルパー 系

System.ThrowHelper

ThrowIf～系

Microsoft.Toolkit.Diagnostics.ThrowHelper

Guard / ガード 系

CommunityToolkit.Diagnostics.Guard

LINQは遅い？

新しい.NETを使う

PLINQで並列処理する

LINQ高速化ライブラリを使う

間違った使い方をしない

LINQ 高速化ライブラリ比較

プロファイル

ベンチマーク

BenchmarkDotNet

benchmark.net使用時注意

アプリprofiler

ローカルstaticフィールドはReadOnlySpan<T>＋コレクション式でできる

[Peanut Butter]Span<T>のコピーで長さの判定を入れると速くなる（.NET8）

newしない初期値・リセット

文字列 string.Empty

配列 Array.Empty<T>()

コレクション Enumerable.Empty<T>()

リスト ImmutableArray<T>.Empty

Span<T> Span<T>.Empty

コレクション式で初期化 []

半公式の高速化ライブラリ

.NET Community Toolkit

.NEXT

Microsoft.IO.RecyclableMemoryStream

実行時最適化

Tiered Compilation

On-Stack Replacement

情報

前提：C#の文字列`string`はネックになりがち

`String.Intern` はそのままだと自作キャッシュに負けるがNativeAOTで逆転

決して最速じゃない配列`T[]`

`ThrowHelper`/ スローヘルパー系

`ThrowIf～`系

Guard / ガード系

ローカルstaticフィールドは`ReadOnlySpan<T>`＋コレクション式でできる

[Peanut Butter]`Span<T>`のコピーで長さの判定を入れると速くなる（.NET8）

文字列 `string.Empty`

配列 `Array.Empty<T>()`

コレクション `Enumerable.Empty<T>()`

リスト `ImmutableArray<T>.Empty`

Span<T> `Span<T>.Empty`

コレクション式で初期化 `[]`