<h1>C# における <code>Nullable&#x3C;T></code> の大小比較について</h1>
<code>Nullable&#x3C;T></code> (<code>int?</code> など) の大小の比較をする際に、片方が <code>null</code> の場合の挙動がいつもわからなくなるので調べたメモ。
たとえば、以下の関数を考える。
<pre><code class="hljs language-csharp">bool Hoge(int? x, int? y)
{
 return x &#x3C; y;
}
</code></pre>
この関数をコンパイルすると、以下のようになる。
<pre><code class="hljs language-csharp">private bool Hoge(Nullable&#x3C;int> x, Nullable&#x3C;int> y)
{
 Nullable&#x3C;int> num = x;
 Nullable&#x3C;int> num2 = y;
 return (num.GetValueOrDefault() &#x3C; num2.GetValueOrDefault()) &#x26; (num.HasValue &#x26; num2.HasValue);
}
</code></pre>
つまり、x, y のどちらか一方でも <code>null</code> の場合はつねに <code>false</code> を返し、両方が <code>null</code> でないときに通常の比較を行う。

# C# における `Nullable<T>` の大小比較について

`Nullable<T>` (`int?` など) の大小の比較をする際に、片方が `null` の場合の挙動がいつもわからなくなるので調べたメモ。

たとえば、以下の関数を考える。

```csharp
bool Hoge(int? x, int? y)
{
 return x < y;
}
```

この関数をコンパイルすると、以下のようになる。

```csharp
private bool Hoge(Nullable<int> x, Nullable<int> y)
{
 Nullable<int> num = x;
 Nullable<int> num2 = y;
 return (num.GetValueOrDefault() < num2.GetValueOrDefault()) & (num.HasValue & num2.HasValue);
}
```

つまり、x, y のどちらか一方でも `null` の場合はつねに `false` を返し、両方が `null` でないときに通常の比較を行う。

C# における Nullable<T> の大小比較について

<h1>C ドライブがパンパンになったらすること</h1>
会社で使っている 開発マシン（windows） の C ドライブがパンパンになって困ったのでやったことをメモ。
<ul>
<li>ゴミ箱を空にする
<ul>
<li>意外と見落としがち</li>
</ul>
</li>
<li>ダウンロードフォルダの中身を削除
<ul>
<li>ゴミがたまりがち</li>
</ul>
</li>
<li>いらないアプリをひたすら削除
<ul>
<li>最近使ってなかった JetBrains 系のツール</li>
<li>Docker Desktop</li>
</ul>
</li>
<li>(.NET 開発者の場合) Visual Studio のインストール項目の見直し
<ul>
<li>Azure 用の機能とかいらないものを削除</li>
<li>古い .NET Framework SDK とかいらないなら削除</li>
</ul>
</li>
<li>ディスククリーンアップツールでのクリーンアップ
<ul>
<li>これだと一時ファイルは消えなかった</li>
</ul>
</li>
<li>nuget パッケージキャッシュをクリア
<ul>
<li><code>dotnet nuget locals -c all</code></li>
<li>古いものがたまり続けていくのでかなり肥大化していた</li>
</ul>
</li>
<li><code>~/AppData/Local/Temp</code> の中身を削除
<ul>
<li>クリーンアップツールで消せなかったので手動で削除</li>
<li>いくつか消せないものはあった</li>
<li>手動で消すのは若干乱暴なのでできればツールで消すべき</li>
</ul>
</li>
</ul>


# C ドライブがパンパンになったらすること

会社で使っている 開発マシン（windows） の C ドライブがパンパンになって困ったのでやったことをメモ。

- ゴミ箱を空にする
  - 意外と見落としがち
- ダウンロードフォルダの中身を削除
  - ゴミがたまりがち
- いらないアプリをひたすら削除
  - 最近使ってなかった JetBrains 系のツール
  - Docker Desktop
- (.NET 開発者の場合) Visual Studio のインストール項目の見直し
  - Azure 用の機能とかいらないものを削除
  - 古い .NET Framework SDK とかいらないなら削除
- ディスククリーンアップツールでのクリーンアップ
  - これだと一時ファイルは消えなかった
- nuget パッケージキャッシュをクリア
  - `dotnet nuget locals -c all`
  - 古いものがたまり続けていくのでかなり肥大化していた
- `~/AppData/Local/Temp` の中身を削除
  - クリーンアップツールで消せなかったので手動で削除
  - いくつか消せないものはあった
  - 手動で消すのは若干乱暴なのでできればツールで消すべき


C ドライブがパンパンになったらすること

First メソッドの実装をざっくり読む (Deep Dive into LINQ #3)

First メソッドを作ってみる (Deep Dive into LINQ #2)

First メソッドの使い方 (Deep Dive into LINQ #1)

<h1>ジェネリックメソッドをリフレクションで呼び出す</h1>
<h2>重要キーワード</h2>
<ul>
<li><code>MakeGenericMethod</code> メソッド</li>
</ul>
<h2>はじめに</h2>
ASP.NET Core の開発では、いろいろな型に対して同じメソッドを繰り返し実行したい場合がまれにあります。たとえば最近では DI が当たり前になっていますが、 <code>IServiceCollection</code> の拡張メソッド群は引数は何も取らずに型引数だけ指定することも多いです。
このとき、毎回 <code>AddSingleton&#x3C;T></code> や <code>Configure&#x3C;T></code> を手書きするのではなく、型の配列に対してループで実行できたらいいなと思うことがあります。
今回は、このような用途のためにジェネリックメソッドをリフレクションで扱う方法について説明します。
<h2>非ジェネリックメソッドの呼び出し</h2>
<code>Type</code> を引数にとる非ジェネリックメソッドの場合は、下記のように書けます。
<pre><code class="hljs language-csharp">void Main()
{
 var types = new[] {typeof(string), typeof(int), typeof(decimal)};
 foreach (var type in types) 
 {
 Add(type);
 }
}

// 型に対してなにかする関数
static void Add(Type type) {var types = new Type[]()
</code></pre>
<h2>ジェネリックメソッドの呼び出し</h2>
では、以下のようなメソッドの定義ではどうでしょうか。
<pre><code class="hljs language-csharp">public class SampleClass
{
 // 型の名前をコンソールに出すジェネリックメソッド
 public static void StaticMethod&#x3C;T>() 
 {
 Console.WriteLine(typeof(T).FullName);
 }
 
 public void InstanceMethod&#x3C;T>(string prefix) 
 {
 Console.WriteLine(prefix + typeof(T).Name);
 }
}
</code></pre>
このクラスのメソッドは <code>Type</code> 引数を受け取らず、ジェネリック版のみ提供されていますので、上記のような簡単なループで実装することはできません。
このような場合は、リフレクションを使って次のようにします。
<pre><code class="hljs language-csharp">void Main()
{
 var types = new[] {typeof(string), typeof(int), typeof(decimal)};
 
 // StaticMethod メソッド（型引数が埋まっていない）を取得
 var staticMethodInfo = typeof(SampleClass)
 .GetMethod(name: nameof(SampleClass.StaticMethod), 
 genericParameterCount: 1, // 型引数の数を指定
 bindingAttr: BindingFlags.Public | BindingFlags.Static, // public static なメンバを検索
 binder: null, 
 types: Array.Empty&#x3C;Type>(),
 modifiers: null);
 
 // InstanceMethod メソッド（型引数が埋まっていない）を取得
 var instanceMethodInfo = typeof(SampleClass)
 .GetMethod(name: nameof(SampleClass.InstanceMethod), 
 genericParameterCount: 1, // 型引数の数を指定
 bindingAttr: BindingFlags.Public | BindingFlags.Instance, // public なメンバを検索
 binder: null,
 types: new[] { typeof(string)}, // 引数の型の配列。
 modifiers: null);
 
 var instance = new SampleClass();
 
 foreach (var type in types) 
 {
 staticMethodInfo!.MakeGenericMethod(type) // 型引数を指定してジェネリックメソッドを作る
 .Invoke(null, null); // 実行。 引数なしの static メソッドなので引数は両方 null

 instanceMethodInfo!.MakeGenericMethod(type) // 型引数を指定してジェネリックメソッドを作る
 .Invoke(instance, new object[] {"prefix string "}); // 実行。 引数ありのインスタンスメソッドなので、第1引数にインスタンス、第2引数に引数の配列
 }
}
</code></pre>
まず、対象のメソッドが定義されている型の <code>Type</code> インスタンスを取得します。
ここでは <code>typeof</code> 演算子で取得しています。
次に、<code>Type.GetMethod</code> メソッドを使用して呼び出したいメソッドの <code>MethodInfo</code> を取得します。
このとき、ジェネリック型引数が埋まっていない中途半端な状態の <code>MethodInfo</code> が返ってくるため、<code>MakeGenericMethod</code> メソッドで型引数をきちんと埋めてあげましょう。
型引数が埋まった <code>MethodInfo</code> がとれれば、あとは非ジェネリックメソッドと同じように <code>Invoke</code> に引数を渡して実行すれば OK です。
<h2>少し複雑な呼び出しテクニック</h2>
これでめでたくジェネリックメソッドの呼び出しができたわけですが、もう少し複雑で長い呼び出しが必要になった場合はどうでしょうか？
メソッドを 2 つ呼び出すだけでも十分ややこしく、読みにくいコードなのに、呼び出すメソッドがもっと増えて、戻り値や引数の処理（すべて <code>object</code> 型で扱います！）まで入ってきたら、もうほとんど書いた本人以外わからないコードになってしまいます。
そこで、次のようなテクニックをおすすめしたいと思います。
<ul>
<li>まず一連の処理を書いた ジェネリックメソッド を一つ作る</li>
<li>リフレクションを使って、そのジェネリックメソッドを一つだけ呼び出す</li>
</ul>
この方法で先程の例を書き直してみると、次のようになります。
<pre><code class="hljs language-csharp">void Main()
{
 var types = new[] {typeof(string), typeof(int), typeof(decimal)};
 
 // InvokeMultipleMethods を呼び出す MethodInfo
 var instanceMethodInfo = typeof(SampleClass)
 .GetMethod(name: nameof(SampleClass.InstanceMethod), 
 genericParameterCount: 1, // 型引数の数を指定
 bindingAttr: BindingFlags.Public | BindingFlags.Instance, // public なメンバを検索
 binder: null,
 types: new[] { typeof(string)}, // 引数の型の配列。
 modifiers: null);
 
 var instance = new SampleClass();
 
 foreach (var type in types) 
 {
 instanceMethodInfo!.MakeGenericMethod(type) // 型引数を指定してジェネリックメソッドを作る
 .Invoke(instance, new object[] {"prefix string "}); // 実行。 引数ありのインスタンスメソッドなので、第1引数にインスタンス、第2引数に引数の配列
 }
}

public class SampleClass
{
 // このメソッドに処理を書いておいて呼び出す
 public void InvokeMultipleMethods&#x3C;T>(string prefix)
 {
 // ここは普通のメソッド呼び出しなので普通に読める
 StaticMethod&#x3C;T>();
 this.InstanceMethod&#x3C;T>(prefix);
 }
 
 // 型に対してなにかするジェネリックメソッド
 public static void StaticMethod&#x3C;T>() 
 {
 Console.WriteLine(typeof(T).FullName);
 }
 
 public void InstanceMethod&#x3C;T>(string prefix) 
 {
 Console.WriteLine(prefix + typeof(T).Name);
 }
}
</code></pre>
さきほどよりもスッキリしたのではないでしょうか。
このようにすることで、リフレクション回数を減らし、可読性も上げることができます。
<h2>適用シーンと他の手法</h2>
今回のようなリフレクションを用いた手法は、「起動時に一回だけすべての型に対して行う」ような場合に威力を発揮します。 DI の設定などはこれにあたります。
実行中に何度も呼ばれるような箇所にリフレクションを使ってしまうと、かなり低速なコードになってしまいます。
逆に、起動時に一回だけであればリフレクションの遅さもあまり気にならず、また非常に手軽なメタプログラミングの方法として重宝するでしょう。
他に同様のことができるものとしては、コード生成という手法があります。
コード生成にも以下のようにいろいろと種類があります。
近年は SourceGenerator が登場し、静的コード生成の選択肢が広がっています。
<ul>
<li>動的コード生成（実行時にコード生成、型情報はリフレクションをもとに解析して使う）
<ul>
<li>IL
<ul>
<li>IL(.NET における中間言語)を直接書いて、実行時にプログラムを動的に作り出して実行</li>
<li>○ 一度生成してしまえば高速</li>
<li>○ C# では書けないような高度な操作も可能</li>
<li>☓ IL は読み書きの難易度が非常に高い</li>
</ul>
</li>
<li>Expression Tree
<ul>
<li>式木というものを用いてプログラムを動的に生成する</li>
<li>○ 一度生成すれば高速</li>
<li>△ IL よりはお手軽だが、それなりに学習コストもあり制限もある</li>
</ul>
</li>
</ul>
</li>
<li>静的コード生成（ビルド時やコードを書くときにコード生成）
<ul>
<li>T4
<ul>
<li>○ 古くからある安定した技術</li>
<li>○ T4 という独自の記法でテンプレートを書き、テキストファイルを生成</li>
<li>○ テキストファイルであればなんでも （.cs ファイルも）生成でき、ビルド対象にもできる</li>
<li>○ 事前に生成するものがわかっている場合に便利</li>
<li>△ ユーザが T4 を書く必要があるため、広く配布するには若干不向き</li>
</ul>
</li>
<li>SourceGenerator
<ul>
<li>○ 最新の手法</li>
<li>○ ビルド処理に介入、コンパイラが使う構文木（プログラムの構文を解析して木にしたもの）を自由に読み取って、それをもとにコードを生成できる</li>
<li>○ ユーザに余計なことを気にさせず、使い勝手の良いコード生成ができる</li>
<li>○ コードを書いた瞬間にインクリメンタルにコード生成が可能なので使い心地が良い</li>
<li>○ アナライザと連携して高度な安全性や書き心地を提供できる</li>
<li>○ 普通に C# で書いた処理と実行速度が変わらない</li>
<li>☓ 構文木を正しく読み取って処理する必要があるが、ドキュメントが少なく難易度が高い</li>
<li>☓ ちょっとしたことをするには実装コストが高い</li>
</ul>
</li>
</ul>
</li>
</ul>
最後は一般的な話になってしまいましたが、メタプログラミング手法にも様々なものがあり、それぞれに向き不向きがありますから、場面に応じた最適な手法を選択することが大切です。
静的なコード生成では一般にパフォーマンスの低下は一切見られず、また生成されたコードは誰でも読めるため、メンテナンス性も高いです。しかし、コード生成のための追加の作業をユーザに要求したり、ビルドパフォーマンスに影響を与える場合があります。また、やはり静的な生成では実現できないこともあります。
それに対して、リフレクションや動的生成は非常に強力な手法ですが、参照がほとんど追えなかったり、カプセル化を破壊できるという点で、使い方を誤ればコードベースの品質を破滅的に低下させる要因にもなり得ます。また、よくない実装によって実行速度を低下させてしまう可能性もあります。
特にチーム開発においては、全員にわかりやすく、安全にメンテできることが大前提となることが多いです。無理に難しい手法を導入すると、逆に生産性を落とすことにもつながります。レベルアップのためにはエレガントな手法の追求も大切ですが、ときには愚直に書くことを選択する勇気を持つことも大切です。

# ジェネリックメソッドをリフレクションで呼び出す

## 重要キーワード

- `MakeGenericMethod` メソッド

## はじめに

ASP.NET Core の開発では、いろいろな型に対して同じメソッドを繰り返し実行したい場合がまれにあります。たとえば最近では DI が当たり前になっていますが、 `IServiceCollection` の拡張メソッド群は引数は何も取らずに型引数だけ指定することも多いです。
このとき、毎回 `AddSingleton<T>` や `Configure<T>` を手書きするのではなく、型の配列に対してループで実行できたらいいなと思うことがあります。

今回は、このような用途のためにジェネリックメソッドをリフレクションで扱う方法について説明します。

## 非ジェネリックメソッドの呼び出し

`Type` を引数にとる非ジェネリックメソッドの場合は、下記のように書けます。

```csharp
void Main()
{
 var types = new[] {typeof(string), typeof(int), typeof(decimal)};
 foreach (var type in types) 
 {
 Add(type);
 }
}

// 型に対してなにかする関数
static void Add(Type type) {var types = new Type[]()
```

## ジェネリックメソッドの呼び出し

では、以下のようなメソッドの定義ではどうでしょうか。

```csharp
public class SampleClass
{
 // 型の名前をコンソールに出すジェネリックメソッド
 public static void StaticMethod<T>() 
 {
 Console.WriteLine(typeof(T).FullName);
 }
 
 public void InstanceMethod<T>(string prefix) 
 {
 Console.WriteLine(prefix + typeof(T).Name);
 }
}
```

このクラスのメソッドは `Type` 引数を受け取らず、ジェネリック版のみ提供されていますので、上記のような簡単なループで実装することはできません。
このような場合は、リフレクションを使って次のようにします。

```csharp
void Main()
{
 var types = new[] {typeof(string), typeof(int), typeof(decimal)};
 
 // StaticMethod メソッド（型引数が埋まっていない）を取得
 var staticMethodInfo = typeof(SampleClass)
 .GetMethod(name: nameof(SampleClass.StaticMethod), 
 genericParameterCount: 1, // 型引数の数を指定
 bindingAttr: BindingFlags.Public | BindingFlags.Static, // public static なメンバを検索
 binder: null, 
 types: Array.Empty<Type>(),
 modifiers: null);
 
 // InstanceMethod メソッド（型引数が埋まっていない）を取得
 var instanceMethodInfo = typeof(SampleClass)
 .GetMethod(name: nameof(SampleClass.InstanceMethod), 
 genericParameterCount: 1, // 型引数の数を指定
 bindingAttr: BindingFlags.Public | BindingFlags.Instance, // public なメンバを検索
 binder: null,
 types: new[] { typeof(string)}, // 引数の型の配列。
 modifiers: null);
 
 var instance = new SampleClass();
 
 foreach (var type in types) 
 {
 staticMethodInfo!.MakeGenericMethod(type) // 型引数を指定してジェネリックメソッドを作る
 .Invoke(null, null); // 実行。 引数なしの static メソッドなので引数は両方 null

 instanceMethodInfo!.MakeGenericMethod(type) // 型引数を指定してジェネリックメソッドを作る
 .Invoke(instance, new object[] {"prefix string "}); // 実行。 引数ありのインスタンスメソッドなので、第1引数にインスタンス、第2引数に引数の配列
 }
}
```


まず、対象のメソッドが定義されている型の `Type` インスタンスを取得します。
ここでは `typeof` 演算子で取得しています。
次に、`Type.GetMethod` メソッドを使用して呼び出したいメソッドの `MethodInfo` を取得します。
このとき、ジェネリック型引数が埋まっていない中途半端な状態の `MethodInfo` が返ってくるため、`MakeGenericMethod` メソッドで型引数をきちんと埋めてあげましょう。

型引数が埋まった `MethodInfo` がとれれば、あとは非ジェネリックメソッドと同じように `Invoke` に引数を渡して実行すれば OK です。


## 少し複雑な呼び出しテクニック

これでめでたくジェネリックメソッドの呼び出しができたわけですが、もう少し複雑で長い呼び出しが必要になった場合はどうでしょうか？
メソッドを 2 つ呼び出すだけでも十分ややこしく、読みにくいコードなのに、呼び出すメソッドがもっと増えて、戻り値や引数の処理（すべて `object` 型で扱います！）まで入ってきたら、もうほとんど書いた本人以外わからないコードになってしまいます。

そこで、次のようなテクニックをおすすめしたいと思います。

- まず一連の処理を書いた **ジェネリックメソッド** を一つ作る
- リフレクションを使って、そのジェネリックメソッドを一つだけ呼び出す

この方法で先程の例を書き直してみると、次のようになります。

```csharp
void Main()
{
 var types = new[] {typeof(string), typeof(int), typeof(decimal)};
 
 // InvokeMultipleMethods を呼び出す MethodInfo
 var instanceMethodInfo = typeof(SampleClass)
 .GetMethod(name: nameof(SampleClass.InstanceMethod), 
 genericParameterCount: 1, // 型引数の数を指定
 bindingAttr: BindingFlags.Public | BindingFlags.Instance, // public なメンバを検索
 binder: null,
 types: new[] { typeof(string)}, // 引数の型の配列。
 modifiers: null);
 
 var instance = new SampleClass();
 
 foreach (var type in types) 
 {
 instanceMethodInfo!.MakeGenericMethod(type) // 型引数を指定してジェネリックメソッドを作る
 .Invoke(instance, new object[] {"prefix string "}); // 実行。 引数ありのインスタンスメソッドなので、第1引数にインスタンス、第2引数に引数の配列
 }
}

public class SampleClass
{
 // このメソッドに処理を書いておいて呼び出す
 public void InvokeMultipleMethods<T>(string prefix)
 {
 // ここは普通のメソッド呼び出しなので普通に読める
 StaticMethod<T>();
 this.InstanceMethod<T>(prefix);
 }
 
 // 型に対してなにかするジェネリックメソッド
 public static void StaticMethod<T>() 
 {
 Console.WriteLine(typeof(T).FullName);
 }
 
 public void InstanceMethod<T>(string prefix) 
 {
 Console.WriteLine(prefix + typeof(T).Name);
 }
}
```

さきほどよりもスッキリしたのではないでしょうか。
このようにすることで、リフレクション回数を減らし、可読性も上げることができます。

## 適用シーンと他の手法

今回のようなリフレクションを用いた手法は、「起動時に一回だけすべての型に対して行う」ような場合に威力を発揮します。 DI の設定などはこれにあたります。
実行中に何度も呼ばれるような箇所にリフレクションを使ってしまうと、かなり低速なコードになってしまいます。
逆に、起動時に一回だけであればリフレクションの遅さもあまり気にならず、また非常に手軽なメタプログラミングの方法として重宝するでしょう。

他に同様のことができるものとしては、コード生成という手法があります。
コード生成にも以下のようにいろいろと種類があります。
近年は SourceGenerator が登場し、静的コード生成の選択肢が広がっています。

- 動的コード生成（実行時にコード生成、型情報はリフレクションをもとに解析して使う）
 - IL
 - IL(.NET における中間言語)を直接書いて、実行時にプログラムを動的に作り出して実行
 - ○ 一度生成してしまえば高速
 - ○ C# では書けないような高度な操作も可能
 - ☓ IL は読み書きの難易度が非常に高い
 - Expression Tree
 - 式木というものを用いてプログラムを動的に生成する
 - ○ 一度生成すれば高速
 - △ IL よりはお手軽だが、それなりに学習コストもあり制限もある
- 静的コード生成（ビルド時やコードを書くときにコード生成）
 - T4
 - ○ 古くからある安定した技術
 - ○ T4 という独自の記法でテンプレートを書き、テキストファイルを生成
 - ○ テキストファイルであればなんでも （.cs ファイルも）生成でき、ビルド対象にもできる
 - ○ 事前に生成するものがわかっている場合に便利
 - △ ユーザが T4 を書く必要があるため、広く配布するには若干不向き
 - SourceGenerator
 - ○ 最新の手法
 - ○ ビルド処理に介入、コンパイラが使う構文木（プログラムの構文を解析して木にしたもの）を自由に読み取って、それをもとにコードを生成できる
 - ○ ユーザに余計なことを気にさせず、使い勝手の良いコード生成ができる
 - ○ コードを書いた瞬間にインクリメンタルにコード生成が可能なので使い心地が良い
 - ○ アナライザと連携して高度な安全性や書き心地を提供できる
 - ○ 普通に C# で書いた処理と実行速度が変わらない 
 - ☓ 構文木を正しく読み取って処理する必要があるが、ドキュメントが少なく難易度が高い
 - ☓ ちょっとしたことをするには実装コストが高い

最後は一般的な話になってしまいましたが、メタプログラミング手法にも様々なものがあり、それぞれに向き不向きがありますから、場面に応じた最適な手法を選択することが大切です。

静的なコード生成では一般にパフォーマンスの低下は一切見られず、また生成されたコードは誰でも読めるため、メンテナンス性も高いです。しかし、コード生成のための追加の作業をユーザに要求したり、ビルドパフォーマンスに影響を与える場合があります。また、やはり静的な生成では実現できないこともあります。

それに対して、リフレクションや動的生成は非常に強力な手法ですが、参照がほとんど追えなかったり、カプセル化を破壊できるという点で、使い方を誤ればコードベースの品質を破滅的に低下させる要因にもなり得ます。また、よくない実装によって実行速度を低下させてしまう可能性もあります。

特にチーム開発においては、全員にわかりやすく、安全にメンテできることが大前提となることが多いです。無理に難しい手法を導入すると、逆に生産性を落とすことにもつながります。レベルアップのためにはエレガントな手法の追求も大切ですが、ときには愚直に書くことを選択する勇気を持つことも大切です。

ジェネリックメソッドをリフレクションで呼び出す

<h1>数学の勉強法について</h1>
わたしは現在数学科の 2 年生で、長期履修制度の対象者のため 1 年に一度教務幹事の先生との面談がある。今回の面談で、数学をどうやって勉強したらよいか、ということについて少しお話を聞けたのでメモしておく。
Q. 数学の勉強はどのくらいのレベルを目指してやればいいのか。なにをすれば、「ちゃんと理解した」ということになるのか。教科書の内容を完璧に再現できるようなレベルまで目指すべきか。
A. なにをもって「理解した」と言えるのか、その線を明確に引くのは難しい。しかしたとえば、数学科の専門科目の講義担当の先生方は、突然教科書やノートを取り上げられても、講義の内容をほとんど完璧に再現できるだろう。これは「理解した」と言っても良いレベルではないか。
ただ数学科のふつうの 2 年生が、全体の山の形が見えていない段階で、講義を受けながらそのレベルをいきなり目指すのは難しいだろう（不可能ではない）。
学生のうちはまずは解決したい問題を見つけてみると、勉強の道筋が見えやすい。数学の研究というのも、古い歴史を見ればなにか難しい問題があって、それを解決するために研究されてきたという側面がある。足元を固めるような勉強ばかりやって、ただの物知りなおじさんになってもしょうがない。
たとえば大学院への進学を目指しているなら、院試の問題を見てみるのが一つの方法。
たとえば（この具体例はうろ覚え）、<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>e</mi><mrow><mo>−</mo><msup><mi>x</mi><mn>2</mn></msup></mrow></msup></mrow><annotation encoding="application/x-tex">e^{-x^2}</annotation></semantics></math>e−x2 の積分のような問題は院試レベルでは必ず解けなければならない。
少し考えてみると、<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo>∫</mo><msup><mi>e</mi><mrow><mo>−</mo><msup><mi>x</mi><mn>2</mn></msup></mrow></msup><mi>d</mi><mi>x</mi></mrow><annotation encoding="application/x-tex">\int e^{-x^2} dx</annotation></semantics></math>∫e−x2dx は初等関数で簡単に表すことはできないことがわかるが、広義積分 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msubsup><mo>∫</mo><mn>0</mn><mi mathvariant="normal">∞</mi></msubsup><msup><mi>e</mi><mrow><mo>−</mo><msup><mi>x</mi><mn>2</mn></msup></mrow></msup><mi>d</mi><mi>x</mi></mrow><annotation encoding="application/x-tex">\int_{0}^{\infty} e^{-x^2} dx</annotation></semantics></math>∫0∞​e−x2dx は <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mfrac><msqrt><mi>π</mi></msqrt><mn>2</mn></mfrac></mrow><annotation encoding="application/x-tex">\frac{\sqrt{π}}{2}</annotation></semantics></math>2π<svg xmlns="http://www.w3.org/2000/svg" width="400em" height="1.08em" viewBox="0 0 400000 1080" preserveAspectRatio="xMinYMin slice"><path d="M95,702
c-2.7,0,-7.17,-2.7,-13.5,-8c-5.8,-5.3,-9.5,-10,-9.5,-14
c0,-2,0.3,-3.3,1,-4c1.3,-2.7,23.83,-20.7,67.5,-54
c44.2,-33.3,65.8,-50.3,66.5,-51c1.3,-1.3,3,-2,5,-2c4.7,0,8.7,3.3,12,10
s173,378,173,378c0.7,0,35.3,-71,104,-213c68.7,-142,137.5,-285,206.5,-429
c69,-144,104.5,-217.7,106.5,-221
l0 -0
c5.3,-9.3,12,-14,20,-14
H400000v40H845.2724
s-225.272,467,-225.272,467s-235,486,-235,486c-2.7,4.7,-9,7,-19,7
c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z
M834 80h400000v40h-400000z"></path></svg>​​ になることが知られている。この話は「そうなることを知っているから」できたという側面もあるが、おそらくこの部分の記憶だけを取り上げられても、重積分の知識があれば再現できるだろう。2 年生の重積分を最後まで勉強すれば、これがわかるようになる。
もっと簡単な 1 年生の範囲の例として、行列 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>A</mi></mrow><annotation encoding="application/x-tex">A</annotation></semantics></math>A に対して <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>A</mi><mi>m</mi></msup></mrow><annotation encoding="application/x-tex">A^m</annotation></semantics></math>Am を求める問題を考えてみる。調べていくと、<math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>A</mi></mrow><annotation encoding="application/x-tex">A</annotation></semantics></math>A が対角行列なら <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>A</mi><mi>m</mi></msup></mrow><annotation encoding="application/x-tex">A^m</annotation></semantics></math>Am は簡単に求まることがわかる。もう少し調べると、「対角化」という操作を覚えればいろいろな行列についてこの問題が解けるようになることがわかる。そこで対角化について勉強する。対角化についてわかると、「線形代数 5 級」から「線形代数 4 級」のような感じになれる。こうやって、解きたい問題を見つけて、それについて勉強していくと目的がつかみやすい。
このようにして勉強を積み重ねていくと、ある程度まではわかるようになる。ただ、これは細い一本道をたくさん作っているだけなので抜けもれが出てくる。まずはそのような状態でも良い。完璧に理解することを目指してなにもできなくなるよりかは、抜け漏れがある状態でも勉強できたほうがよい。大学の授業では、ひとつの細い線ではなくて、ある程度足元を広く学べるように講義が展開されていくので、講義もうまく使って補っていくと良い。
院試以外にも、指定教科書の最後のほうを読んでみるとか、そういうのも目的を掴むためには有用である。


# 数学の勉強法について

わたしは現在数学科の 2 年生で、長期履修制度の対象者のため 1 年に一度教務幹事の先生との面談がある。今回の面談で、数学をどうやって勉強したらよいか、ということについて少しお話を聞けたのでメモしておく。

Q. 数学の勉強はどのくらいのレベルを目指してやればいいのか。なにをすれば、「ちゃんと理解した」ということになるのか。教科書の内容を完璧に再現できるようなレベルまで目指すべきか。

A. なにをもって「理解した」と言えるのか、その線を明確に引くのは難しい。しかしたとえば、数学科の専門科目の講義担当の先生方は、突然教科書やノートを取り上げられても、講義の内容をほとんど完璧に再現できるだろう。これは「理解した」と言っても良いレベルではないか。

ただ数学科のふつうの 2 年生が、全体の山の形が見えていない段階で、講義を受けながらそのレベルをいきなり目指すのは難しいだろう（不可能ではない）。
学生のうちはまずは解決したい問題を見つけてみると、勉強の道筋が見えやすい。数学の研究というのも、古い歴史を見ればなにか難しい問題があって、それを解決するために研究されてきたという側面がある。足元を固めるような勉強ばかりやって、ただの物知りなおじさんになってもしょうがない。

たとえば大学院への進学を目指しているなら、院試の問題を見てみるのが一つの方法。

たとえば（この具体例はうろ覚え）、$e^{-x^2}$ の積分のような問題は院試レベルでは必ず解けなければならない。
少し考えてみると、$\int e^{-x^2} dx$ は初等関数で簡単に表すことはできないことがわかるが、広義積分 $\int_{0}^{\infty} e^{-x^2} dx$ は $\frac{\sqrt{π}}{2}$ になることが知られている。この話は「そうなることを知っているから」できたという側面もあるが、おそらくこの部分の記憶だけを取り上げられても、重積分の知識があれば再現できるだろう。2 年生の重積分を最後まで勉強すれば、これがわかるようになる。

もっと簡単な 1 年生の範囲の例として、行列 $A$ に対して $A^m$ を求める問題を考えてみる。調べていくと、$A$ が対角行列なら $A^m$ は簡単に求まることがわかる。もう少し調べると、「対角化」という操作を覚えればいろいろな行列についてこの問題が解けるようになることがわかる。そこで対角化について勉強する。対角化についてわかると、「線形代数 5 級」から「線形代数 4 級」のような感じになれる。こうやって、解きたい問題を見つけて、それについて勉強していくと目的がつかみやすい。

このようにして勉強を積み重ねていくと、ある程度まではわかるようになる。ただ、これは細い一本道をたくさん作っているだけなので抜けもれが出てくる。まずはそのような状態でも良い。完璧に理解することを目指してなにもできなくなるよりかは、抜け漏れがある状態でも勉強できたほうがよい。大学の授業では、ひとつの細い線ではなくて、ある程度足元を広く学べるように講義が展開されていくので、講義もうまく使って補っていくと良い。

院試以外にも、指定教科書の最後のほうを読んでみるとか、そういうのも目的を掴むためには有用である。


数学の勉強法について

CloudWatch Logs のログを Athena で手軽に分析する

# LINQ のコツ 2021 年版 (2)

この記事は 2021 年現在の LINQ のコツを，基本的なところから最新の応用例まで書いていく連載です．背景や予定に関しては， [前回の記事](/articles/20210903-linq-1) のまえがきをご覧ください．

## 2. materialization

今回は LINQ の materialization（マテリアライゼーション） についてです．
materialization とは，実体化などという意味で， LINQ においてはとくに要素の評価戦略が lazy な（またはその可能性のある）シーケンスから，すべての要素が計算済みの具体的なコレクションを得るような操作のことを指すことが多いです．例としては， `ToArray` などの操作がそれにあたります．

### 2.1. 実行と評価のタイミングを整理する

これ以降混乱するといけないので，もういちど評価戦略についてのおさらいと，用語の再定義をします．操作自体の実行と，それぞれの要素の評価との 2 つのタイミングが組み合わさるため，一般的な lazy/eager の区別よりも少し複雑なものになっています．

前回の記事で扱った **遅延評価** (lazy evaluation) とは，それぞれの要素の評価をその要素が必要になるまで保留するという評価戦略でした．
実行タイミングとしては遅れて実行されるので，**遅延実行** (deferred execution) と呼ばれます．

この遅延実行 (deferred execution) の評価戦略にはもうひとつ， **先行評価** (eager evaluation) と呼ばれるものがあります．これは，要素の評価自体はその場で行わないけれども，ひとつめの要素を評価する際にほかの要素もすべて評価してしまうようなものです．
具体的には，要素をグループ化する `GroupBy` や並べ替えを行う `OrderBy` などの操作がこれにあたります．

そして，実行タイミングには遅延実行の反対である **即時実行** (immediate execution) があります．その操作の時点でただちにすべての評価を済ませるような， `ToArray` などの操作がこれに分類されます．

まとめると下記のような分類になります．

- 即時実行 (immediate execution) : すぐに実行
- 遅延実行 (deferred execution) : 必要になるまで遅らせて実行
 - 遅延評価 (lazy evaluation) : 必要になった要素だけ評価し，それ以外の要素の評価は遅らせる
 - 先行評価 (eager evaluation) : ひとつめの要素が評価されるタイミングで，すべての要素を評価する

[前回の記事](/articles/20210903-linq-1) では，このうちの deferred execution の lazy evaluation について考えていたことになります．

### 2.2. 各 LINQ メソッドの実行と評価のタイミング

.NET 6 までの LINQ のメソッドについて，実行と評価のタイミングを表にまとめます．
評価については

- immediate: ただちに実行
- deferred / lazy : 遅延実行かつ各要素が遅延評価
- deferred / eager : 遅延実行だがすべての要素を同時に評価

の 3 つの分類にしています．

| method | execution / evaluation |
| ------------------------------ | -------------------------------------------------------------- |
| Aggregate | immediate |
| Any / All | immediate |
| Append / Prepend | deferred / lazy |
| Average | immediate |
| Chunk | deferred / lazy (size 分だけ先行評価) |
| Concat | deferred / lazy |
| Contains | immediate |
| Count | immediate |
| DefaultIfEmpty | deferred / lazy |
| Distinct | deferred / lazy |
| ElementAt / ElementAtOrDefault | immediate |
| Except | deferred / lazy (2 つめの引数は最初の要素の評価時にすべて評価) |
| First / FirstOrDefault | immediate |
| GroupJoin | deferred / lazy (inner は最初の要素の評価時にすべて評価) |
| GroupBy | deferred / eager |
| Intersect | deferred / lazy (2 つめの引数は最初の要素の評価時にすべて評価) |
| Join | deferred / lazy (inner は最初の要素の評価時にすべて評価) |
| Last | immediate |
| Lookup | immediate |
| Min/Max | immediate |
| OfType | deferred / lazy |
| OrderBy | deferred / eager |
| Range | deferred / lazy |
| Repeat | deferred / lazy |
| Reverse | deferred / eager |
| Select | deferred / lazy |
| SelectMany | deferred / lazy |
| SequenceEqual | immediate |
| Single / SingleOrDefault | immediate |
| Skip | deferred / lazy |
| Sum | immediate |
| Take | deferred / lazy |
| ToArray | immediate |
| ToList | immediate |
| ToDictionary | immediate |
| ToHashSet | immediate |
| Union | deferred / lazy |
| Where | deferred / lazy |
| Zip | deferred / lazy |

こうして並べてみると，少し法則が見えてきます．

- `IEnumerable<T>` を返すメソッドはほとんど遅延実行かつ遅延評価 (例: `Select`, `Where`, `OfType`)
- `bool` など，まったく違う型を返すメソッドは即時実行 (例: `Sum`, `Any`, `First`)
- 遅延実行かつ先行評価なのは `GroupBy` と `Reverse` のみ
 - これらは原理的にひとつめの要素を知るためにすべての要素を評価しなければならない
- `List<T>` や `Dictionary<TKey, TValue>` などの具体的なコレクションを返すメソッドは即時実行 (例: `LookUp`, `ToHashSet`, `ToArray`)
 - この操作を **materialize** と呼ぶ

### 2.3. materialization の基本

[前回の記事](/articles/20210903-linq-1) で見たように， LINQ の基本は遅延評価 (lazy) であり，一度評価した結果も保持しないのでした．
これはパフォーマンス上有利に働く場面が多いのですが，要素を複数回列挙(multiple enumeration) したい場合には，要素の評価も複数回おこなわれてしまいます．

#### 2.3.1. 例: lazy な要素の multiple enumeration

```csharp
void Main()
{
 IEnumerable<int> seq = GenerateSequence();

 // 5 以下の数のみになるようにフィルタし，各要素を string に変換する
 IEnumerable<string> stringSeq = seq
 .Where(x => x <= 5)
 .Select(x => x.ToString());

 // 2 回の foreach と Count() でそれぞれ要素の評価が行われる
 foreach (string s in stringSeq) Console.WriteLine($"foreach1: {s}");
 foreach (string s in stringSeq) Console.WriteLine($"foreach2: {s}");
 Console.WriteLine($"count: {stringSeq.Count()}")
}

// 1 から 10 までの lazy なシーケンスをつくる
IEnumerable<int> GenerateSequence()
{
 foreach (var x in Enumerable.Range(1, 10))
 {
 Console.WriteLine($"enumerate {x}");
 yield return x;
 }
}
```

#### 2.3.2. 要素の再評価を避けるための materialization

複数回の列挙の際に，要素の評価を 1 回で済ませるためには

- 一度評価した要素の評価結果を覚えておく
- いったん配列などに materialize したうえで利用する

といった方法が考えられます．

1 つめの「評価結果を覚えておく」という方法ですが，これは便利な場面もあるものの，場合によっては大きなメモリ領域を必要としたり，実装が複雑化してしまいます．また，標準の LINQ はこのような機構を提供していません．

一方 materialize する方法では，実際に配列などを作ってしまうという単純な手法のため，実現も容易でハマりどころもあまりありません．また，標準の LINQ で `ToArray` などの materialize のための操作が提供されているので，こちらがよく使われる一般的な方法です．

#### 2.3.3. 例: `ToArray` による materialize

```csharp
void Main()
{
 IEnumerable<int> seq = GenerateSequence();

 // 5 以下の数のみになるようにフィルタし，各要素を string に変換する
 string[] stringSeq = seq
 .Where(x => x <= 5)
 .Select(x => x.ToString())
 .ToArray(); // この時点ですべての要素が評価される

 // これ以降要素の再評価は発生しない
 foreach (string s in stringSeq) Console.WriteLine($"foreach1: {s}");
 foreach (string s in stringSeq) Console.WriteLine($"foreach2: {s}");
 Console.WriteLine($"count: {stringSeq.Count()}")
}

// 1 から 10 までの lazy なシーケンスをつくる
IEnumerable<int> GenerateSequence()
{
 foreach (var x in Enumerable.Range(1, 10))
 {
 Console.WriteLine($"enumerate {x}");
 yield return x;
 }
}
```

このように， materialization は場合によっては強力なパフォーマンス改善手法となります．

### 2.4. materialization のパフォーマンスへの影響

materialization は LINQ を使う上でぜひおさえておきたいテクニックですが，利用は最小限にとどめ，濫用は避けるべきです．
ここでは， materialization のパフォーマンスへの影響を調べます．

#### 2.4.1. 例: materialization の濫用

たとえば，つぎのような実装では materialization の濫用によってパフォーマンスが著しく低下します．

```csharp
void Main()
{
 IEnumerable<int> seq = GenerateSequence();

 // 5 以下の数のみになるようにフィルタし，各要素を string に変換する
 string[] stringSeq = seq
 .ToArray() // materialize!
 .Where(x => x <= 5)
 .ToArray() // materialize!
 .Select(x => x.ToString())
 .ToArray(); // materialize!

 // これ以降要素の再評価は発生しない．．．が．．．
 foreach (string s in stringSeq) Console.WriteLine($"foreach1: {s}");
 foreach (string s in stringSeq) Console.WriteLine($"foreach2: {s}");
}

// 1 から 100000 までの lazy なシーケンスをつくる
IEnumerable<int> GenerateSequence()
{
 foreach (var x in Enumerable.Range(1, 100000))
 {
 Console.WriteLine($"enumerate {x}");
 yield return x;
 }
}
```

この場合，本当に必要なのは最後の `ToArray` だけで，途中の `ToArray` は必要ありません．

#### 2.4.2. 例: materialization の適正な使用

```csharp
void Main()
{
 IEnumerable<int> seq = GenerateSequence();

 // 5 以下の数のみになるようにフィルタし，各要素を string に変換する
 string[] stringSeq = seq
 .Where(x => x <= 5)
 .Select(x => x.ToString())
 .ToArray(); // 最後に一度だけ materialize

 // これ以降要素の再評価は発生しない．
 foreach (string s in stringSeq) Console.WriteLine($"foreach1: {s}");
 foreach (string s in stringSeq) Console.WriteLine($"foreach2: {s}");
}

// 1 から 100000 までの lazy なシーケンスをつくる
IEnumerable<int> GenerateSequence()
{
 foreach (var x in Enumerable.Range(1, 100000))
 {
 Console.WriteLine($"enumerate {x}");
 yield return x;
 }
}
```

このように，基本的に materialization は利用の直前だけで十分です．
また，何度も列挙を行わない場合はそもそも materialization の必要がありません．

#### 2.4.3. materialization のベンチマーク

では materialization がどのくらいパフォーマンスに影響を与えるのか，測定してみましょう．

下記のようにベンチマーク用のコードを用意します． このコードは [GitHub](https://github.com/wipiano/wipiano-net-csharp-examples/blob/main/ToArrayBenchmark/Program.cs) に置いてあります．

```csharp
class Program
{
 static void Main(string[] args)
 {
 var config = new ManualConfig()
 .AddJob(Job.ShortRun)
 .AddExporter(MarkdownExporter.GitHub)
 .AddDiagnoser(MemoryDiagnoser.Default)
 .AddLogger(ConsoleLogger.Default)
 .AddColumnProvider(DefaultColumnProviders.Instance);

 BenchmarkRunner.Run<Benchmark1>(config);
 }
}

public class Benchmark1
{
 private TestData[] _source;

 private readonly Consumer _consumer = new();

 [GlobalSetup]
 public void Setup()
 {
 // 10万件のテストデータを用意
 _source = GenerateTestData().Take(100000).ToArray();
 }

 // materialize しない
 [Benchmark(Baseline = true)]
 public void WithoutMaterialize()
 {
 var results = _source
 .Where(x => x.Name == "taro")
 .Select(x => (x.Id, x.Name.ToUpper()))
 .Where(x => x.Id > 100)
 .Select(x => x.Id);

 // 2 回 results を使う
 results.Consume(_consumer);
 results.Consume(_consumer);
 }

 // 適正な materialize
 [Benchmark]
 public void MaterializeOnce()
 {
 var results = _source
 .Where(x => x.Name == "taro")
 .Select(x => (x.Id, x.Name.ToUpper()))
 .Where(x => x.Id > 100)
 .Select(x => x.Id)
 .ToArray();

 // 2 回 results を使う
 results.Consume(_consumer);
 results.Consume(_consumer);
 }

 // materialize の濫用
 [Benchmark]
 public void MaterializeMany()
 {
 var results = _source
 .ToArray()
 .Where(x => x.Name == "taro")
 .ToArray()
 .Select(x => (x.Id, x.Name.ToUpper()))
 .ToArray()
 .Where(x => x.Id > 100)
 .ToArray()
 .Select(x => x.Id)
 .ToArray();

 // 2 回 results を使う
 results.Consume(_consumer);
 results.Consume(_consumer);
 }

 private static IEnumerable<TestData> GenerateTestData()
 {
 Random random = new Random();
 var names = new[] { "foo", "bar", "hanako", "taro", "jiro", "kyoko" };
 int id = 0;

 while (true)
 yield return new TestData(++id, names[random.Next(0, names.Length - 1)]);
 }

 private record TestData(int Id, string Name);
}
```

ベンチマークの結果は下記のようになります．

```
| Method | Mean | Error | StdDev | Ratio | RatioSD | Gen 0 | Gen 1 | Gen 2 | Allocated |
|------------------- |---------:|----------:|----------:|------:|--------:|---------:|---------:|---------:|----------:|
| WithoutMaterialize | 3.622 ms | 0.1726 ms | 0.0095 ms | 1.00 | 0.00 | 601.5625 | - | - | 1,236 KB |
| MaterializeOnce | 2.005 ms | 0.1706 ms | 0.0093 ms | 0.55 | 0.00 | 375.0000 | 42.9688 | - | 836 KB |
| MaterializeMany | 5.197 ms | 6.3204 ms | 0.3464 ms | 1.43 | 0.09 | 492.1875 | 492.1875 | 335.9375 | 2,818 KB |
```

まず，materialize をまったくしないものでは 3.622 ms かかっており，メモリは 1236KB 消費しています．
次に，適正に materialize を行ったものでは， 2.005ms になっており，メモリも 836KB とパフォーマンスが良くなっています．
逆に，materialize を濫用したものでは 5.197ms もかかってしまっていて，メモリ消費量も多くなっています．

このように， materialize をただしく行うことで， LINQ を使った処理のパフォーマンスを改善することができます．
また， materialize は注意深く行わないと，逆にパフォーマンスが低下します．

### 2.4. materialization のまとめ

ポイントをまとめると下記のようになります．

- LINQ の評価タイミングにはいろいろなものがある
- 遅延評価の欠点を補うために materialization を活用しよう
- materialization の濫用は厳禁

次回の記事では，SelectMany の活用について書く予定です．

LINQ のコツ 2021 年版 (2) - materialization

LINQ のコツ 2021 年版 (1) - LINQ の遅延評価

Visual Studio で launchsettings.json を生成させない方法

async stream を理解する [使いどころ編]

async stream を理解する [基本編]

数学科に入りたい社会人へ

<h1>async な lock をしよう</h1>
Qiita から移行
--
C# では，非同期なメソッドでは lock が使えません．この記事ではそれでも lock したいときはどうするのっていうお話をします．
たとえば，こんなふうにダブルチェックロッキングしたいとしますね．
<pre><code class="hljs language-csharp">// これが複数のスレッドから非同期に呼ばれる
private static async ValueTask 条件満たしたらなんかするAsync()
{
 if (条件)
 {
 lock (_lockObj)
 {
 if (条件)
 {
 await なんかすごく重いIOバウンドなやつAsync();
 }
 }
 }
}
</code></pre>
lock ステートメントは非同期メソッド内で使えないので，実際にはこのコードはコンパイルが通りません． じゃあどうしようか，といって，一番ラクな逃げ道は同期にしちゃうことです．カンタンカンタン．
<pre><code class="hljs language-csharp">// これが複数のスレッドから非同期に呼ばれる
private static void 条件満たしたらなんかする()
{
 if (条件)
 {
 lock (_lockObj)
 {
 if (条件)
 {
 なんかすごく重いIOバウンドなやつAsync().Wait();
 }
 }
 }
}
</code></pre>
<code>Task</code> だって <code>Wait</code> しちゃえばただの同期，これはちゃんと動きます．でもここで「いやなんのための async なんだよ」ってなりますよね． lock したいだけなのに，そのために非同期の恩恵を捨て去る，そんなことやっちゃダメです．
じゃあ最新技術をこね回して難しいコード書くのかっていうとそんなことはなく，むしろ全く逆で古くからある技術を使います．そう，セマフォ です． セマフォっていうと OS の機能で，プロセス間の資源のアクセス制御に使うイメージですが，.NET にはプロセス内で利用するための <code>SemaphoreSlim</code> クラスがあります． セマフォといっても結局待たなきゃいけないでしょって話なんですが， <code>SemaphoreSlim</code> クラスには非同期で待てる <code>WaitAsync()</code> メソッドがあるわけです． これをつかうと完全に非同期な lock が実現できるわけですね． これはもうパターンが固定なので，ちょっと汎用的に <code>AsyncLock</code> なんていうクラスを作っておくとどこでも使えます． やってることもとてもカンタンなので，作り方さえ覚えてしまえばとっさのときにも書けます．
<pre><code class="hljs language-csharp">/// &#x3C;summary>
/// async な文脈での lock を提供します．
/// Lock 開放のために，必ず処理の完了後に LockAsync が生成した IDisposable を Dispose してください．
/// &#x3C;/summary>
public sealed class AsyncLock
{
 private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(1, 1);

 public async Task&#x3C;IDisposable> LockAsync()
 {
 await _semaphore.WaitAsync();
 return new Handler(_semaphore);
 }

 private sealed class Handler : IDisposable
 {
 private readonly SemaphoreSlim _semaphore;
 private bool _disposed = false;

 public Handler(SemaphoreSlim semaphore)
 {
 _semaphore = semaphore;
 }

 public void Dispose()
 {
 if (!_disposed)
 {
 _semaphore.Release();
 _disposed = true;
 }
 }
 }
}
</code></pre>
面倒な人はこれをコピペでいいです．使うときは， lock 構文の代わりに using 構文を使います．これによって， semaphore の管理を忘れて lock という意味を持たせた見た目のコードを書けます．
たとえば，最初の例を書いてみるとこんな感じです．
<pre><code class="hljs language-csharp">private static readonly s_lock = new AsyncLock();
private static async Task 条件満たしたらなんかするAsync()
{
 if (条件)
 {
 using (await s_lock.LockAsync())
 {
 if (条件)
 {
 await なんかすごく重いIOバウンドなやつAsync();
 }
 }
 }
}
</code></pre>
lock が using に変わっただけで，あとはあまり変わりません．でもこれはコンパイルも通るし，ちゃんと非同期でパフォーマンスよく動きます．
というわけで，いままで <code>.Wait</code> しちゃってた方，今日からは <code>await</code> しましょう！

# async な lock をしよう

Qiita から移行

--

C# では，非同期なメソッドでは lock が使えません．この記事ではそれでも lock したいときはどうするのっていうお話をします．

たとえば，こんなふうにダブルチェックロッキングしたいとしますね．

```csharp
// これが複数のスレッドから非同期に呼ばれる
private static async ValueTask 条件満たしたらなんかするAsync()
{
 if (条件)
 {
 lock (_lockObj)
 {
 if (条件)
 {
 await なんかすごく重いIOバウンドなやつAsync();
 }
 }
 }
}
```

lock ステートメントは非同期メソッド内で使えないので，実際にはこのコードはコンパイルが通りません． じゃあどうしようか，といって，一番ラクな逃げ道は同期にしちゃうことです．カンタンカンタン．

```csharp
// これが複数のスレッドから非同期に呼ばれる
private static void 条件満たしたらなんかする()
{
 if (条件)
 {
 lock (_lockObj)
 {
 if (条件)
 {
 なんかすごく重いIOバウンドなやつAsync().Wait();
 }
 }
 }
}
```

`Task` だって `Wait` しちゃえばただの同期，これはちゃんと動きます．でもここで「いやなんのための async なんだよ」ってなりますよね． lock したいだけなのに，そのために非同期の恩恵を捨て去る，そんなことやっちゃダメです．

じゃあ最新技術をこね回して難しいコード書くのかっていうとそんなことはなく，むしろ全く逆で古くからある技術を使います．そう，セマフォ です． セマフォっていうと OS の機能で，プロセス間の資源のアクセス制御に使うイメージですが，.NET にはプロセス内で利用するための `SemaphoreSlim` クラスがあります． セマフォといっても結局待たなきゃいけないでしょって話なんですが， `SemaphoreSlim` クラスには非同期で待てる `WaitAsync()` メソッドがあるわけです． これをつかうと完全に非同期な lock が実現できるわけですね． これはもうパターンが固定なので，ちょっと汎用的に `AsyncLock` なんていうクラスを作っておくとどこでも使えます． やってることもとてもカンタンなので，作り方さえ覚えてしまえばとっさのときにも書けます．

```csharp
/// <summary>
/// async な文脈での lock を提供します．
/// Lock 開放のために，必ず処理の完了後に LockAsync が生成した IDisposable を Dispose してください．
/// </summary>
public sealed class AsyncLock
{
 private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(1, 1);

 public async Task<IDisposable> LockAsync()
 {
 await _semaphore.WaitAsync();
 return new Handler(_semaphore);
 }

 private sealed class Handler : IDisposable
 {
 private readonly SemaphoreSlim _semaphore;
 private bool _disposed = false;

 public Handler(SemaphoreSlim semaphore)
 {
 _semaphore = semaphore;
 }

 public void Dispose()
 {
 if (!_disposed)
 {
 _semaphore.Release();
 _disposed = true;
 }
 }
 }
}
```

面倒な人はこれをコピペでいいです．使うときは， lock 構文の代わりに using 構文を使います．これによって， semaphore の管理を忘れて lock という意味を持たせた見た目のコードを書けます．

たとえば，最初の例を書いてみるとこんな感じです．

```csharp
private static readonly s_lock = new AsyncLock();
private static async Task 条件満たしたらなんかするAsync()
{
 if (条件)
 {
 using (await s_lock.LockAsync())
 {
 if (条件)
 {
 await なんかすごく重いIOバウンドなやつAsync();
 }
 }
 }
}
```

lock が using に変わっただけで，あとはあまり変わりません．でもこれはコンパイルも通るし，ちゃんと非同期でパフォーマンスよく動きます．

というわけで，いままで `.Wait` しちゃってた方，今日からは `await` しましょう！

async な lock をしよう

# `Span<T>` のつかいみち

Qiita から移行 (2019/12/10 投稿)

--

これは、 C# Advent Calendar 2019 の 10 日目の記事です（遅刻すみません！）。 前の記事は、 @Xeltica さんの C# 用ゲームエンジンを自作した話 です。

.NET Core 2.1 で使えるようになってしばらくたった `Span<T>` ですが、まだ使えてないよ〜って C#er のみなさんもまだまだいらっしゃると思うので、ぼくが書いたコードを晒していきます。 もっと速くなるよ、とかあれば教えてください！

## 文字列系

ここでのコツは、 `Span<char>#ToString()` をうまく使うことと、 `stackalloc` でスタック領域を活用することです。 ヒープアロケーションを極力避けることで、高速に動作させます。

### `byte[]` -> 16 進数 への変換

byte 配列を 16 進数の文字列に変換する拡張メソッドです。

```csharp
/// <summary>
/// 16 進数の文字列に変換します
/// </summary>
public static string ToHexString(this byte[] source, bool upperCase = false)
{
 Span<char> buffer = stackalloc char[source.Length * 2];
 source.WriteAsHexChars(buffer, out _, upperCase);
 return buffer.ToString();
}

/// <summary>
/// バイト列を 16 進数の列として書き込みます
/// </summary>
public static void WriteAsHexChars(this ReadOnlySpan<byte> bytes, Span<char> dest, out int charsWritten,
 bool upperCase = false)
{
 charsWritten = 0;

 foreach (byte b in bytes)
 {
 b.WriteAsHexChars(dest.Slice(charsWritten), out var count, upperCase);
 charsWritten += count;
 }
}

/// <summary>
/// バイトを 16 進数として書き込みます
/// </summary>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static void WriteAsHexChars(this byte b, Span<char> dest, out int charsWritten, bool upperCase = false)
{
 ReadOnlySpan<char> source = upperCase ? s_byteToHexUpper[b] : s_byteToHexLower[b];
 source.CopyTo(dest);
 charsWritten = source.Length; // 2 固定のはず
}

// byte -> char[] に変換するための 配列
private static readonly char[][] s_byteToHexLower =
 Enumerable.Range(0, 256).Select(x => ((byte) x).ToString("x2").ToCharArray()).ToArray();

private static readonly char[][] s_byteToHexUpper =
 Enumerable.Range(0, 256).Select(x => ((byte) x).ToString("X2").ToCharArray()).ToArray();
```

### snake_case -> PascalCase への変換

スネークケースからパスカルケースへの変換をします。これは他の変換 (例: Pascal -> snake) にも応用できます。

```csharp
public static string SnakeCaseToPascalCase(this string snake)
{
 ReadOnlySpan<char> snakeSpan = snake;
 Span<char> buffer = stackalloc char[snakeSpan.Length];

 int bufferPos = 0;
 bool toUpper = true;
 for (var i = 0; i < snake.Length; i++)
 {
 var target = snakeSpan[i];

 if (target == '_')
 {
 toUpper = true;
 }
 else
 {
 buffer[bufferPos++] = toUpper ? char.ToUpper(target) : target;
 toUpper = false;
 }
 }

 return buffer.Slice(0, bufferPos).ToString();
}
```

### MD5 ハッシュの計算

MD5 ハッシュの計算にも Span が活用できます。 MD5CryptoServiceProvider はすこしラップしてあげると使いやすくなりますが、ここでも Span を活用します。 Span のコツは、できるだけ最後まで Span で扱うこと (= スタックを最大限に活用)、だと思ってます。 さっきの `byte[]` -> 16 進への変換も利用して、16 進数の書き込みまで Span だけでやってます。

```csharp
/// <summary>
/// MD5 ヘルパ
/// </summary>
public static class Md5HashHelper
{
 // md5 インスタンスキャッシュ
 // このインスタンスはメソッド呼び出しによって内部状態が遷移するため
 // かならず内部状態の初期化を行うこと。
 // 呼び出し後に自動的に内部状態が初期化されるメソッドは ComputeHash, TryComputeHash のみです。
 [ThreadStatic] private static MD5CryptoServiceProvider t_md5 = null;

 /// <summary>
 /// MD5 ハッシュのバイト長
 /// </summary>
 public const int HashBytesLength = 16;

 /// <summary>
 /// MD5 ハッシュの十六進表記の文字数
 /// </summary>
 public const int HashHexStringLength = 32;

 /// <summary>
 /// キャッシュを使用するか
 /// </summary>
 /// <remarks>
 /// true の場合、 MD5CryptoServiceProvider のインスタンスをスレッドごとにキャッシュして使用します。
 /// false の場合は毎回新しい MD5CryptoServiceProvider のインスタンスを使用します。
 /// </remarks>
 public static bool UseCache { get; set; } = true;

 /// <summary>
 /// 指定したバイト配列のハッシュ値を計算します。
 /// </summary>
 public static byte[] ComputeHash(byte[] buffer)
 {
 return ComputeHash(buffer, 0, buffer.Length);
 }

 /// <summary>
 /// 指定したバイト配列の指定した領域のハッシュ値を計算します。
 /// </summary>
 public static byte[] ComputeHash(byte[] buffer, int offset, int count)
 {
 var md5 = RentUnsafe();
 var result = md5.ComputeHash(buffer, offset, count);
 ReturnUnsafe(md5);
 return result;
 }

 /// <summary>
 /// 指定した Stream オブジェクトのハッシュ値を計算します
 /// </summary>
 public static byte[] ComputeHash(Stream inputStream)
 {
 var md5 = RentUnsafe();
 var result = md5.ComputeHash(inputStream);
 ReturnUnsafe(md5);
 return result;
 }

 /// <summary>
 /// 入力バイト列のハッシュ値を計算し、出力バイト列にコピーします。
 /// </summary>
 public static bool TryComputeHash(ReadOnlySpan<byte> source, Span<byte> destination, out int bytesWritten)
 {
 var md5 = RentUnsafe();
 var result = md5.TryComputeHash(source, destination, out bytesWritten);
 ReturnUnsafe(md5);
 return result;
 }

 /// <summary>
 /// 入力バイト列のハッシュ値を計算し、16 進数表記で出力文字列にコピーします
 /// </summary>
 public static bool TryComputeHash(ReadOnlySpan<byte> source, Span<char> destination, out int charsWritten, bool upperCase = false)
 {
 Span<byte> buffer = stackalloc byte[16];
 if (TryComputeHash(source, buffer, out var bytesWritten))
 {
 ((ReadOnlySpan<byte>) buffer).WriteAsHexChars(destination, out charsWritten, upperCase);
 return true;
 }
 else
 {
 charsWritten = 0;
 return false;
 }
 }

 /// <summary>
 /// MD5 インスタンスを借用します。
 /// </summary>
 private static MD5CryptoServiceProvider RentUnsafe()
 {
 if (!UseCache || t_md5 == null)
 {
 return new MD5CryptoServiceProvider();
 }
 else
 {
 var md5 = t_md5;
 t_md5 = null;
 return md5;
 }
 }

 /// <summary>
 /// MD5 インスタンスをキャッシュに返却します。
 /// ※返却前に内部状態が汚染されたインスタンスを返却しないこと。
 /// </summary>
 private static void ReturnUnsafe(MD5CryptoServiceProvider md5)
 {
 if (UseCache && t_md5 == null && md5 != null)
 {
 t_md5 = md5;
 }
 }
}
```

## Utf8Json のカスタムフォーマッタ

JSON のフォーマッタを書くときも Span を活用できます。

### Enum を CamelCase にするフォーマッタ

PascalCase な enum メンバを CamelCase でシリアライズしたいことがあって書いてみました。

```csharp
public class CamelCaseEnumFormatter<T> : IJsonFormatter<T>
 where T : struct
{
 public void Serialize(ref JsonWriter writer, T value, IJsonFormatterResolver formatterResolver)
 {
 var str = value.ToString();
 Span<char> buffer = stackalloc char[str.Length];
 str.AsSpan().CopyTo(buffer);
 buffer[0] = char.ToLower(buffer[0]);
 writer.WriteString(buffer.ToString());
 }

 public T Deserialize(ref JsonReader reader, IJsonFormatterResolver formatterResolver)
 {
 var str = reader.ReadString();
 return Enum.Parse<T>(str, true);
 }
}
```

## おまけ: StringBuilder

これは半分遊びですが、スタック上で複雑な文字列を構築していきたいときのための、StringBuilder の Span 実装です。

```csharp
public ref struct SpanStringBuilder
{
 private Span<char> _buffer;

 private int _index;

 public SpanStringBuilder(Span<char> buffer)
 {
 _buffer = buffer;
 _index = 0;
 }

 public void Write(ReadOnlySpan<char> str)
 {
 str.CopyTo(_buffer.Slice(_index));
 _index += str.Length;
 }

 public void WriteLine(ReadOnlySpan<char> str)
 {
 Write(str);
 Write(Environment.NewLine);
 }

 public void Write(char c)
 {
 _buffer[_index++] = c;
 }

 public void Write(int value)
 {
 if (!value.TryFormat(_buffer.Slice(_index), out var charsWritten))
 {
 throw new OutOfMemoryException("buffer のサイズが足りません");
 }

 _index += charsWritten;
 }

 public Span<char> AsSpan() => _buffer.Slice(0, _index);

 public override string ToString() => AsSpan().ToString();
}
```

Span<T>のつかいみち

<h1>C# で messagepack vs json 比較</h1>
Messagepack の良さを社内に布教するためにベンチマークを取ったので転載しておく。
個人的には MessagePack + LZ4 の Typeless がおすすめ。 messagepack は可読性が・・・と言われることが多いけど、 Typeless なシリアライズなら型情報がつくので、 dynamic にデシリアライズして json を吐くような小さいツールさえ作っておけば gzip 圧縮した json とそこまで使い勝手は変わらないのでは？と思う。 パフォーマンスの面では messagepack が有利。json + gzip はファイルサイズは小さくなったけど、パフォーマンスが許容できるかどうか。
ベンチマークに使ったコードは <a href="https://github.com/wipiano/benchmark-json-vs-msgpack-csharp">こちら</a>
<h2>ファイルサイズ</h2>
<pre><code class="hljs language-python">json: 137,248,217 bytes
json + gzip: 045,170,640 bytes
msgpack: 084,959,431 bytes
msgpack + lz4: 061,381,468 bytes
msgpack (typeless): 083,949,384 bytes
msgpack (typeless) + lz4: 060,776,211 bytes
</code></pre>
<h2>パフォーマンス</h2>
<pre><code class="hljs language-ruby">BenchmarkDotNet=v0.12.0, OS=ubuntu 19.04
Intel Core i7-8700 CPU 3.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=3.0.100
 [Host] : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
 ShortRun : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT

Job=ShortRun IterationCount=3 LaunchCount=1
WarmupCount=3 

| Method | Mean | Error | StdDev | Ratio | RatioSD | Gen 0 | Gen 1 | Gen 2 | Allocated | Completed Work Items | Lock Contentions |
|----------------------- |-----------:|----------:|---------:|------:|--------:|----------:|----------:|----------:|----------:|---------------------:|-----------------:|
| Utf8JsonWithType | 1,001.4 ms | 337.02 ms | 18.47 ms | 1.00 | 0.00 | 1000.0000 | 1000.0000 | - | 642.99 MB | 3.0000 | - |
| Utf8JsonWithTypeGz | 4,134.0 ms | 987.83 ms | 54.15 ms | 4.13 | 0.13 | 7000.0000 | 7000.0000 | 2000.0000 | 814.09 MB | 3.0000 | - |
| Utf8JsonTypeless | 984.2 ms | 50.38 ms | 2.76 ms | 0.98 | 0.02 | 1000.0000 | 1000.0000 | - | 642.99 MB | 2.0000 | - |
| Utf8JsonTypelessGz | 4,194.6 ms | 777.21 ms | 42.60 ms | 4.19 | 0.04 | 7000.0000 | 7000.0000 | 2000.0000 | 814.08 MB | 3.0000 | - |
| MessagePackWithType | 390.3 ms | 231.84 ms | 12.71 ms | 0.39 | 0.02 | - | - | - | 336.9 MB | 2.0000 | - |
| MessagePackWithTypeLz4 | 537.4 ms | 66.94 ms | 3.67 ms | 0.54 | 0.01 | 2000.0000 | 2000.0000 | - | 395.79 MB | 2.0000 | - |
| MessagePackTypeless | 368.1 ms | 2.59 ms | 0.14 ms | 0.37 | 0.01 | - | - | - | 335.94 MB | 2.0000 | - |
| MessagePackTypelessLz4 | 515.2 ms | 75.83 ms | 4.16 ms | 0.51 | 0.01 | 2000.0000 | 2000.0000 | - | 394.22 MB | 2.0000 | - |

// * Legends *
Mean : Arithmetic mean of all measurements
Error : Half of 99.9% confidence interval
StdDev : Standard deviation of all measurements
Ratio : Mean of the ratio distribution ([Current]/[Baseline])
RatioSD : Standard deviation of the ratio distribution ([Current]/[Baseline])
Gen 0 : GC Generation 0 collects per 1000 operations
Gen 1 : GC Generation 1 collects per 1000 operations
Gen 2 : GC Generation 2 collects per 1000 operations
Allocated : Allocated memory per single operation (managed only, inclusive, 1KB = 1024B)
Completed Work Items : The number of work items that have been processed in ThreadPool (per single operation)
Lock Contentions : The number of times there was contention upon trying to take a Monitor's lock (per single operation)
1 ms : 1 Millisecond (0.001 sec)
</code></pre>


# C# で messagepack vs json 比較

Messagepack の良さを社内に布教するためにベンチマークを取ったので転載しておく。

個人的には MessagePack + LZ4 の Typeless がおすすめ。 messagepack は可読性が・・・と言われることが多いけど、 Typeless なシリアライズなら型情報がつくので、 dynamic にデシリアライズして json を吐くような小さいツールさえ作っておけば gzip 圧縮した json とそこまで使い勝手は変わらないのでは？と思う。 パフォーマンスの面では messagepack が有利。json + gzip はファイルサイズは小さくなったけど、パフォーマンスが許容できるかどうか。

ベンチマークに使ったコードは [こちら](https://github.com/wipiano/benchmark-json-vs-msgpack-csharp)

## ファイルサイズ

```
json:                     137,248,217 bytes
json + gzip:              045,170,640 bytes
msgpack:                  084,959,431 bytes
msgpack + lz4:            061,381,468 bytes
msgpack (typeless):       083,949,384 bytes
msgpack (typeless) + lz4: 060,776,211 bytes
```

## パフォーマンス

```
BenchmarkDotNet=v0.12.0, OS=ubuntu 19.04
Intel Core i7-8700 CPU 3.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=3.0.100
  [Host]   : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
  ShortRun : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT

Job=ShortRun  IterationCount=3  LaunchCount=1
WarmupCount=3  

|                 Method |       Mean |     Error |   StdDev | Ratio | RatioSD |     Gen 0 |     Gen 1 |     Gen 2 | Allocated | Completed Work Items | Lock Contentions |
|----------------------- |-----------:|----------:|---------:|------:|--------:|----------:|----------:|----------:|----------:|---------------------:|-----------------:|
|       Utf8JsonWithType | 1,001.4 ms | 337.02 ms | 18.47 ms |  1.00 |    0.00 | 1000.0000 | 1000.0000 |         - | 642.99 MB |               3.0000 |                - |
|     Utf8JsonWithTypeGz | 4,134.0 ms | 987.83 ms | 54.15 ms |  4.13 |    0.13 | 7000.0000 | 7000.0000 | 2000.0000 | 814.09 MB |               3.0000 |                - |
|       Utf8JsonTypeless |   984.2 ms |  50.38 ms |  2.76 ms |  0.98 |    0.02 | 1000.0000 | 1000.0000 |         - | 642.99 MB |               2.0000 |                - |
|     Utf8JsonTypelessGz | 4,194.6 ms | 777.21 ms | 42.60 ms |  4.19 |    0.04 | 7000.0000 | 7000.0000 | 2000.0000 | 814.08 MB |               3.0000 |                - |
|    MessagePackWithType |   390.3 ms | 231.84 ms | 12.71 ms |  0.39 |    0.02 |         - |         - |         - |  336.9 MB |               2.0000 |                - |
| MessagePackWithTypeLz4 |   537.4 ms |  66.94 ms |  3.67 ms |  0.54 |    0.01 | 2000.0000 | 2000.0000 |         - | 395.79 MB |               2.0000 |                - |
|    MessagePackTypeless |   368.1 ms |   2.59 ms |  0.14 ms |  0.37 |    0.01 |         - |         - |         - | 335.94 MB |               2.0000 |                - |
| MessagePackTypelessLz4 |   515.2 ms |  75.83 ms |  4.16 ms |  0.51 |    0.01 | 2000.0000 | 2000.0000 |         - | 394.22 MB |               2.0000 |                - |

// * Legends *
Mean                 : Arithmetic mean of all measurements
Error                : Half of 99.9% confidence interval
StdDev               : Standard deviation of all measurements
Ratio                : Mean of the ratio distribution ([Current]/[Baseline])
RatioSD              : Standard deviation of the ratio distribution ([Current]/[Baseline])
Gen 0                : GC Generation 0 collects per 1000 operations
Gen 1                : GC Generation 1 collects per 1000 operations
Gen 2                : GC Generation 2 collects per 1000 operations
Allocated            : Allocated memory per single operation (managed only, inclusive, 1KB = 1024B)
Completed Work Items : The number of work items that have been processed in ThreadPool (per single operation)
Lock Contentions     : The number of times there was contention upon trying to take a Monitor's lock (per single operation)
1 ms                 : 1 Millisecond (0.001 sec)
```

C# で messagepack vs json 比較

<h1>.NET Core 3.0 移行のハマりポイントまとめ</h1>
プロダクションで稼働している .NET Core 2.2 (ASP.NET Core 2.2) のシステムを .NET Core 3.0-preview8 に全移行したときのハマりポイントのまとめです。
<a href="https://docs.microsoft.com/ja-jp/aspnet/core/migration/22-to-30?view=aspnetcore-2.2&#x26;tabs=visual-studio">公式の移行手順</a>で説明が無いものを中心にのせています。
<h2>移行前のシステム</h2>
<ul>
<li>ASP.NET Core 2.2 on EC2 (linux)</li>
<li>.NET Core 2.2 on ECS</li>
<li>ASP.NET Core 2.2 on on-premises (ubuntu 18.04)</li>
</ul>
<h2><code>Enumerable.Empty()</code> の実装変更</h2>
これまで、 <code>Enumerable.Empty()</code> は <code>Array.Empty()</code> と同じく空の配列を返していました。 そのため、 <code>Array.Empty()</code> 登場以前の時代のイディオムとして、空の配列が必要な場合に
のように書く場合があります。 現在は <code>Array.Empty()</code> があるので必要ありませんが、今回のシステムでは一部このコードが残っていました。
.NET Core 3.0 では、内部実装が変更され、配列ではなく <code>EmptyPartition&#x3C;T></code> を返すようになっているため、 <code>T[]</code> にキャストできず実行時に例外が発生していました。
<h2>JSON シリアライザの変更</h2>
ASP.NET Core 3.0 ではデフォルトの JSON シリアライザが変更され、 Newtonsoft.Json への依存が削除されているので、互換性を保つためには <code>Microsoft.AspNetCore.Mvc.NewtonsoftJson</code> パッケージへの参照を追加して、 startup で <code>.AddNewtonsoftJson()</code> を呼ぶ必要があります。
Newtonsoft と ASP.NET Core 3.0 標準のシリアライザでは enum のデシリアライズの挙動に違いがありました。
<h2>同期 I/O のブロック</h2>
ASP.NET Core 3.0 では同期 I/O が禁止されました。 同期 I/O を使う処理があると、実行時に例外を吐くようになっています。 パフォーマンスの面から I/O は非同期にすべきですが、依存ライブラリが非同期 I/O に対応していない等の場合は明示的に許可する必要があります。
<code>KestrelServerOptions</code> の <code>AllowSynchronousIO</code> を <code>true</code> に設定することでこの問題を回避できます。

# .NET Core 3.0 移行のハマりポイントまとめ

プロダクションで稼働している .NET Core 2.2 (ASP.NET Core 2.2) のシステムを .NET Core 3.0-preview8 に全移行したときのハマりポイントのまとめです。

[公式の移行手順](https://docs.microsoft.com/ja-jp/aspnet/core/migration/22-to-30?view=aspnetcore-2.2&tabs=visual-studio)で説明が無いものを中心にのせています。

## 移行前のシステム

* ASP.NET Core 2.2 on EC2 (linux)
* .NET Core 2.2 on ECS
* ASP.NET Core 2.2 on on-premises (ubuntu 18.04)

## `Enumerable.Empty()` の実装変更

これまで、 `Enumerable.Empty()` は `Array.Empty()` と同じく空の配列を返していました。 そのため、 `Array.Empty()` 登場以前の時代のイディオムとして、空の配列が必要な場合に

<pre class="code lang-cs" data-lang="cs" data-unlink="">(T[]) Enumerable.Empty<T>()
</pre>

のように書く場合があります。 現在は `Array.Empty()` があるので必要ありませんが、今回のシステムでは一部このコードが残っていました。

.NET Core 3.0 では、内部実装が変更され、配列ではなく `EmptyPartition<T>` を返すようになっているため、 `T[]` にキャストできず実行時に例外が発生していました。

## JSON シリアライザの変更

ASP.NET Core 3.0 ではデフォルトの JSON シリアライザが変更され、 Newtonsoft.Json への依存が削除されているので、互換性を保つためには `Microsoft.AspNetCore.Mvc.NewtonsoftJson` パッケージへの参照を追加して、 startup で `.AddNewtonsoftJson()` を呼ぶ必要があります。

Newtonsoft と ASP.NET Core 3.0 標準のシリアライザでは enum のデシリアライズの挙動に違いがありました。

## 同期 I/O のブロック

ASP.NET Core 3.0 では同期 I/O が禁止されました。 同期 I/O を使う処理があると、実行時に例外を吐くようになっています。 パフォーマンスの面から I/O は非同期にすべきですが、依存ライブラリが非同期 I/O に対応していない等の場合は明示的に許可する必要があります。

`KestrelServerOptions` の `AllowSynchronousIO` を `true` に設定することでこの問題を回避できます。

.NET Core 3.0 移行のハマりポイントまとめ

<h1>今からできる、速くシンプルに LINQ を書くためのコツ 3 個</h1>
<h2>お知らせ</h2>
2021 年 9 月現在，この記事の大幅な改訂版を書いています．
こちらも合わせてご活用ください．
<ul>
<li><a href="/articles/20210903-linq-1">LINQ のコツ 2021 年版 (1) - LINQ の遅延評価</a></li>
</ul>
執筆予定の続編:
<ul>
<li>よい materialization と 悪い materialization</li>
<li>LINQ を pure にしよう</li>
<li><code>SelectMany</code> の活用</li>
<li><code>IAsyncEnumerable</code> と <code>System.Linq.Async</code></li>
<li><code>Parallel.ForEachAsync</code></li>
</ul>
<h2>はじめに</h2>
たびたび 「LINQ が遅い」 と言われているのを見かけるので、どうやったら速く書けるのか、どう書くと遅くなるのかについてまとめてみます。
LINQ は非常に強力で、ぼくが出会った「LINQ 遅い」のほとんどは、 実装の仕方がまずいものばかりです。
LINQ はいくつかポイントを意識するだけでかなり安全に速く書けるようになります。
いろいろとポイントはありますが、 3 つだけに絞って書いてみました。
私自身 C# 書き始めてようやく 2 年たったぐらいなので、間違っているところはバシバシご指摘いただけると嬉しいです。
こちらの記事も参考になるので、合わせてご覧ください。
<a href="http://blog.okazuki.jp/entry/2018/04/20/105738">LINQ を使う時に一般的に気を付けること via C#で Linq を使うより Python の方が 2 倍速かったのでベンチマークをしてみた</a>
<h2>「LINQ が遅い」の 3 パターン</h2>
LINQ は速くないこともたまにあるのですが、大抵の場合は十分なパフォーマンスを提供してくれます。
「LINQ が遅い」 と言う時はだいたい以下のどれかかなと思います。
<ol>
<li>よくわからないけどイメージで「遅そう」と言っている (使いたくない、覚えたくない)</li>
<li>LINQ のしくみがよくわからず、誤った使い方、明らかに遅い書き方をしている (例: なんとなく Count(), ToArray() などしてしまう)</li>
<li>LINQ の内部実装をよく知っているプロフェッショナルが LINQ が適していない場合に「遅い」と言う</li>
</ol>
1 の場合はどうにもできないです。 3 の場合は必要に応じて LINQ 以外の方法を取ることもできますし、 LINQ を使うと判断した場合は最も適切なメソッドを選んで使用できるので遅くなりません。プログラマとしてはここを目指したい。
問題は 2 の場合で、「なんとなく動くものは書けるけど遅い、どこが遅いのかよくわからない」というのが多いです。
今回は最も多いと思われる 2 のパターンをターゲットに書いていきます。
<h2>1. 不用意に要素数を取得しない (Count メソッド)</h2>
一番良く見かけるのがこれです。簡単に書けてしまいますが非常に危険です。
<pre><code class="hljs language-csharp">IEnumerable&#x3C;Hoge> source = // ...

if (source.Count() > 0)
{
 // 要素があるときの処理
}
</code></pre>
<code>IEnumerable&#x3C;T></code> は一般にはカウントを持ちません。いくつ要素があるのかも全部列挙してみないとわかりません。 もしかしたら非常に長かったり、列挙におおきなコストがかかったり、無限につづくシーケンスでそもそもカウントできないかもしれません。
<code>Count</code> メソッドは <code>IEnumerable&#x3C;T></code> の実体が配列の場合などは最適化されていますが，一般には 100 万個要素があったら 100 万個全部を 1 個ずつ列挙して数えていくため非常に遅く、ほとんどの場合に意図していない列挙を発生させます。
もちろん <code>Count</code> の前に <code>Select</code> や <code>Where</code> をかけていて、列挙の際になんらかの計算が発生するような場合にはその計算のコストもかかります。 実体が <code>Count</code> プロパティをもつコレクションである場合には <code>Count</code> プロパティの値を取得するような最適化は入っているものの、本当に「何個あるか知りたい時」以外使うべきでないです。
<code>source.Count() > 0</code> と書くのであれば、代わりに <code>source.Any()</code> と書きましょう。
「ある条件を満たす要素が n 個以上あるかどうかを判定したいとき」には下記のように <code>Skip</code> や <code>Take</code> を使用することで、一部だけの列挙におさえることができます。
<pre><code class="hljs language-csharp">var filtered = source.Where(predicateFunc);

// 列挙した要素を一切使わず、ただ n 個以上あることをたしかめたいとき
// 列挙したものを保存する必要がないのであれば、この方法で無駄な配列確保を避けられる
if (filtered.Skip(n - 1).Any())
{
 // n 個あった時の処理
}

// 列挙した要素を n 個使用するとき
// 複数回同じものに対しての列挙を避けるには、ToArray() が有効。
// ただし、 n が大きくなった場合、それだけ大きい配列が確保されるので注意。これは ToList() でも同様
var part = filtered.Take(n).ToArray();

if (part.Length == n)
{
 foreach (var item in part)
 {
 // なにか処理
 }
}
</code></pre>
<h2>2. なんとなく配列やリストに突っ込まない。ライブラリを作るときはなるべく IEnumerable で受ける。</h2>
<code>ToArray()</code> や <code>ToList()</code> は非常に便利なメソッドですが、ほとんどの場合 LINQ の途中で呼ぶ必要はありません。 たとえば、下記のような ToArray は意味がないばかりか、無駄な配列のためのメモリを確保してパフォーマンスを著しく低下させます。
<pre><code class="hljs language-csharp">IEnumerable&#x3C;Hoge> source = // ...

var array = source.ToArray() // むだな配列生成
 .Select(x => ごにょごにょ)
 .Where(x => ごにょごにょ)
 .Distinct()
 .ToArray(); // むだな配列生成

// foreach するだけならむだな array はいらない
foreach (var x in array)
{
 // なにかする
}
</code></pre>
下記のように書いてもまったく動作上問題がなく、パフォーマンスがよくなります。
<pre><code class="hljs language-csharp">IEnumerable&#x3C;Hoge> source = // ...

var array = source
 .Select(x => ごにょごにょ)
 .Where(x => ごにょごにょ)
 .Distinct();

// foreach するだけならむだな array はいらない
foreach (var x in array)
{
 // なにかする
}
</code></pre>
また、配列である必要がないのに配列で引数を要求するメソッドを書くのはやめましょう。 <code>IEnumerable&#x3C;T></code> で受けましょう。 本当は 1 個ずつ処理するだけのメソッドなのに、渡す側で <code>ToArray()</code> して渡す必要があるのは無駄です。
<h2>3. 巨大なファイルを 1 行ずつ処理するときも、リストはいらない。</h2>
たとえば、こんなコードを書いたことはありませんか？これはほんとうに無駄なのでやめましょう。
<pre><code class="hljs language-csharp">// 1 行ずつ処理したいけど、 LINQ をつかうから IEnumerable&#x3C;T> がほしい。 List&#x3C;T> に Add していこう

List&#x3C;Hoge> sourceList = new List&#x3C;Hoge>();

using (var reader = new StreamReader(stream))
{
 string line;
 while ((line = reader.ReadLine()) != null
 {
 sourceList.Add(MapToHoge(line));
 }
}

sourceList.Select(xxx).Where(xxx). // ...
</code></pre>
こんなふうに書けば、一気に全部読んでしまう必要はまったくありません。
<pre><code class="hljs language-csharp">IEnumerable&#x3C;Hoge> Read()
{
 using (var reader = new StreamReader(stream))
 {
 string line;
 while ((line = reader.ReadLine()) != null
 {
 yield return MapToHoge(line);
 }
 }
}

Read().Select(xxx).Where(xxx) // ...
</code></pre>
あるいは、ファイルから読むことがわかっているならこれでも良いです。
<pre><code class="hljs language-csharp">File.ReadLines("filepath")
 .Select(xxx)
 .Where(xxx)
 . // ...
</code></pre>
<code>File.ReadAllLines</code> メソッドもありますが、こちらはすべてを読んで配列に入れてから返してくるので気をつけましょう。巨大なファイルを読む場合に大量のメモリが必要になります。
<h2>さいごに</h2>
たくさん書きましたが、要するにおなじシーケンスに対しての複数回の列挙や、必要のないものの列挙、巨大なメモリ確保にもっと慎重になりましょうということです。
LINQ は遅延評価が基本ですが、誤った使い方をすればそのメリットを活かせないばかりか、非常に遅いコードが簡単に出来上がってしまいます。
遅いのは LINQ のバグでも、 .NET Core 開発チームの怠慢でも、マシンのスペックが足りないからでもなく、ただ遅くなるように書いたからです。そうでないこともありますが、だいたいそうです。
自分で書いたコードが遅かったり、すっきり書けなかったりして困ったときに、Qiita や twitter に投稿するといろんな人のアドバイスが受けられて楽しいです。
読む人にとってはその投稿についたコメントや、反応の記事のほうが役にたつことがたくさんありますが、最初の投稿がなければそれらの記事も生まれません。
また， LINQ の内部の実装を読むことは非常に勉強になります。
GitHub で .NET Core の完全な実装を読むことができます。
難しく見えるかもしれませんが、単純なもの、きになるものから読んでいくといいと思います。 また、簡単そうなメソッドを自分で書いてみるのも理解するには効果がありました。
LINQ を書く際に気をつけることはこれがすべてではありませんが、ドキュメントやコードをきちんと読んだり、信頼できる先輩にアドバイスをもらったりしながらだんだんと身についていくものだと思います。
あと、 ReSharper などのツールを入れると multiple enumeration の注意を出してくれたりもします。
（ReSharper は他にもいろいろなことを教えてくれる素晴らしい先生になるのでめちゃくちゃおすすめです）
<h2>(おまけ) 記事を書いたきっかけ</h2>
もともと微妙なコードをちょくちょく見かけていて、 LINQ ってそんなに難しいのかなーと思っていたのですが、 twitter で
<a href="https://qiita.com/yniji/items/6585011633289a257888">C#で Linq を使うより Python の方が 2 倍速かったのでベンチマークをしてみた - Qiita</a>
という記事が回ってきました。
公開から短時間でいいねが複数ついていたことから、ほんとうは速くシンプルに書けるにもかかわらず、 LINQ が遅いと判断してしまう人は多いのではないかと思い、 急いで記事を書いている次第です (そもそもこのブログ自体そんなに見られてないのでどの程度効果があるかは疑問ですが)。
この記事の具体的な内容についてはもう十分他の方が指摘などされていると思いますので、ここでは細かく言及しません。 ただ、もし初心者の方が読まれる場合には下記の点だけは頭においてほしいです。
<ol>
<li>(意図的にそうしているとは思いませんが、結果として) 検証用のコードが非常に遅くなるように書かれています。 検証用のコードを改善することでだいぶ速い結果になる、という記事がすでにあります。GroupBy が遅いように書かれていますが、それよりも 無駄な ToList 何度も呼んでいるめにループの回数が増えてしまっていることのほうがはるかに大きな問題です。C# の Linq が python の２倍遅い、は嘘 - Qiita</li>
<li><code>Span&#x3C;T></code> に関しては用途が違うように思います。 Qiita の記事とは全く無関係ですが、 日本語で読める <code>Span&#x3C;T></code> の記事としては <a href="http://ufcpp.net/study/csharp/resource/span/">Span構造体 - C# によるプログラミング入門 | ++C++; // 未確認飛行 C</a> がとても参考になります。</li>
<li>実際には、LINQ に限らず .NET のパフォーマンスの改善や新機能の開発に多くの優秀なエンジニアが取り組んでいます。また、明らかに遅かったり問題があり、改善方法があることが本当にわかっているなら、 issue をあげたり、プルリクエストを送ってみたりする手段は誰にでも開かれています。</li>
</ol>
BenchmarkDotnet を使って LINQ の部分のベンチマークをとってみたところ、標準の LINQ メソッドだけで 3 倍以上高速になりました。
SlowLinq が Qiita の元記事、 NormalLinq がそれを書き直したもの、 UseGroupSum が GroupBy を使わないものです。
<table>
<thead>
<tr>
<th>Method</th>
<th>Mean</th>
<th>Error</th>
<th>Gen 0</th>
<th>Gen 1</th>
<th>Gen 2</th>
<th>Allocated</th>
</tr>
</thead>
<tbody>
<tr>
<td>SlowLinq</td>
<td>321.59 ms</td>
<td>NA</td>
<td>12400.0000</td>
<td>6200.0000</td>
<td>800.0000</td>
<td>78916.81 KB</td>
</tr>
<tr>
<td>NormalLinq</td>
<td>85.77 ms</td>
<td>NA</td>
<td>1400.0000</td>
<td>600.0000</td>
<td>-</td>
<td>8415.32 KB</td>
</tr>
<tr>
<td>UseGroupSum</td>
<td>62.12 ms</td>
<td>NA</td>
<td>-</td>
<td>-</td>
<td>-</td>
<td>147.43 KB</td>
</tr>
</tbody>
</table>

# 今からできる、速くシンプルに LINQ を書くためのコツ 3 個

## お知らせ

2021 年 9 月現在，この記事の大幅な改訂版を書いています．
こちらも合わせてご活用ください．

- [LINQ のコツ 2021 年版 (1) - LINQ の遅延評価](/articles/20210903-linq-1)

執筆予定の続編:

- よい materialization と 悪い materialization
- LINQ を pure にしよう
- `SelectMany` の活用
- `IAsyncEnumerable` と `System.Linq.Async`
- `Parallel.ForEachAsync`

## はじめに

たびたび 「LINQ が遅い」 と言われているのを見かけるので、どうやったら速く書けるのか、どう書くと遅くなるのかについてまとめてみます。
LINQ は非常に強力で、ぼくが出会った「LINQ 遅い」のほとんどは、 実装の仕方がまずいものばかりです。
LINQ はいくつかポイントを意識するだけでかなり安全に速く書けるようになります。
いろいろとポイントはありますが、 3 つだけに絞って書いてみました。

私自身 C# 書き始めてようやく 2 年たったぐらいなので、間違っているところはバシバシご指摘いただけると嬉しいです。

こちらの記事も参考になるので、合わせてご覧ください。

[LINQ を使う時に一般的に気を付けること via C#で Linq を使うより Python の方が 2 倍速かったのでベンチマークをしてみた](http://blog.okazuki.jp/entry/2018/04/20/105738)

## 「LINQ が遅い」の 3 パターン

LINQ は速くないこともたまにあるのですが、大抵の場合は十分なパフォーマンスを提供してくれます。
「LINQ が遅い」 と言う時はだいたい以下のどれかかなと思います。

1. よくわからないけどイメージで「遅そう」と言っている (使いたくない、覚えたくない)
2. LINQ のしくみがよくわからず、誤った使い方、明らかに遅い書き方をしている (例: なんとなく Count(), ToArray() などしてしまう)
3. LINQ の内部実装をよく知っているプロフェッショナルが LINQ が適していない場合に「遅い」と言う

1 の場合はどうにもできないです。 3 の場合は必要に応じて LINQ 以外の方法を取ることもできますし、 LINQ を使うと判断した場合は最も適切なメソッドを選んで使用できるので遅くなりません。プログラマとしてはここを目指したい。
問題は 2 の場合で、「なんとなく動くものは書けるけど遅い、どこが遅いのかよくわからない」というのが多いです。
今回は最も多いと思われる 2 のパターンをターゲットに書いていきます。

## 1. 不用意に要素数を取得しない (Count メソッド)

一番良く見かけるのがこれです。簡単に書けてしまいますが非常に危険です。

```csharp
IEnumerable<Hoge> source = // ...

if (source.Count() > 0)
{
 // 要素があるときの処理
}
```

`IEnumerable<T>` は一般にはカウントを持ちません。いくつ要素があるのかも全部列挙してみないとわかりません。 もしかしたら非常に長かったり、列挙におおきなコストがかかったり、無限につづくシーケンスでそもそもカウントできないかもしれません。
`Count` メソッドは `IEnumerable<T>` の実体が配列の場合などは最適化されていますが，一般には 100 万個要素があったら 100 万個全部を 1 個ずつ列挙して数えていくため非常に遅く、ほとんどの場合に意図していない列挙を発生させます。
もちろん `Count` の前に `Select` や `Where` をかけていて、列挙の際になんらかの計算が発生するような場合にはその計算のコストもかかります。 実体が `Count` プロパティをもつコレクションである場合には `Count` プロパティの値を取得するような最適化は入っているものの、本当に「何個あるか知りたい時」以外使うべきでないです。

`source.Count() > 0` と書くのであれば、代わりに `source.Any()` と書きましょう。

「ある条件を満たす要素が n 個以上あるかどうかを判定したいとき」には下記のように `Skip` や `Take` を使用することで、一部だけの列挙におさえることができます。

```csharp
var filtered = source.Where(predicateFunc);

// 列挙した要素を一切使わず、ただ n 個以上あることをたしかめたいとき
// 列挙したものを保存する必要がないのであれば、この方法で無駄な配列確保を避けられる
if (filtered.Skip(n - 1).Any())
{
 // n 個あった時の処理
}

// 列挙した要素を n 個使用するとき
// 複数回同じものに対しての列挙を避けるには、ToArray() が有効。
// ただし、 n が大きくなった場合、それだけ大きい配列が確保されるので注意。これは ToList() でも同様
var part = filtered.Take(n).ToArray();

if (part.Length == n)
{
 foreach (var item in part)
 {
 // なにか処理
 }
}
```

## 2. なんとなく配列やリストに突っ込まない。ライブラリを作るときはなるべく IEnumerable<T> で受ける。

`ToArray()` や `ToList()` は非常に便利なメソッドですが、ほとんどの場合 LINQ の途中で呼ぶ必要はありません。 たとえば、下記のような ToArray は意味がないばかりか、無駄な配列のためのメモリを確保してパフォーマンスを著しく低下させます。

```csharp
IEnumerable<Hoge> source = // ...

var array = source.ToArray() // むだな配列生成
 .Select(x => ごにょごにょ)
 .Where(x => ごにょごにょ)
 .Distinct()
 .ToArray(); // むだな配列生成

// foreach するだけならむだな array はいらない
foreach (var x in array)
{
 // なにかする
}
```

下記のように書いてもまったく動作上問題がなく、パフォーマンスがよくなります。

```csharp
IEnumerable<Hoge> source = // ...

var array = source
 .Select(x => ごにょごにょ)
 .Where(x => ごにょごにょ)
 .Distinct();

// foreach するだけならむだな array はいらない
foreach (var x in array)
{
 // なにかする
}
```

また、配列である必要がないのに配列で引数を要求するメソッドを書くのはやめましょう。 `IEnumerable<T>` で受けましょう。 本当は 1 個ずつ処理するだけのメソッドなのに、渡す側で `ToArray()` して渡す必要があるのは無駄です。

## 3. 巨大なファイルを 1 行ずつ処理するときも、リストはいらない。

たとえば、こんなコードを書いたことはありませんか？これはほんとうに無駄なのでやめましょう。

```csharp
// 1 行ずつ処理したいけど、 LINQ をつかうから IEnumerable<T> がほしい。 List<T> に Add していこう

List<Hoge> sourceList = new List<Hoge>();

using (var reader = new StreamReader(stream))
{
 string line;
 while ((line = reader.ReadLine()) != null
 {
 sourceList.Add(MapToHoge(line));
 }
}

sourceList.Select(xxx).Where(xxx). // ...
```

こんなふうに書けば、一気に全部読んでしまう必要はまったくありません。

```csharp
IEnumerable<Hoge> Read()
{
 using (var reader = new StreamReader(stream))
 {
 string line;
 while ((line = reader.ReadLine()) != null
 {
 yield return MapToHoge(line);
 }
 }
}

Read().Select(xxx).Where(xxx) // ...
```

あるいは、ファイルから読むことがわかっているならこれでも良いです。

```csharp
File.ReadLines("filepath")
 .Select(xxx)
 .Where(xxx)
 . // ...
```

`File.ReadAllLines` メソッドもありますが、こちらはすべてを読んで配列に入れてから返してくるので気をつけましょう。巨大なファイルを読む場合に大量のメモリが必要になります。

## さいごに

たくさん書きましたが、要するにおなじシーケンスに対しての複数回の列挙や、必要のないものの列挙、巨大なメモリ確保にもっと慎重になりましょうということです。
LINQ は遅延評価が基本ですが、誤った使い方をすればそのメリットを活かせないばかりか、非常に遅いコードが簡単に出来上がってしまいます。
遅いのは LINQ のバグでも、 .NET Core 開発チームの怠慢でも、マシンのスペックが足りないからでもなく、ただ遅くなるように書いたからです。そうでないこともありますが、だいたいそうです。

自分で書いたコードが遅かったり、すっきり書けなかったりして困ったときに、Qiita や twitter に投稿するといろんな人のアドバイスが受けられて楽しいです。
読む人にとってはその投稿についたコメントや、反応の記事のほうが役にたつことがたくさんありますが、最初の投稿がなければそれらの記事も生まれません。

また， LINQ の内部の実装を読むことは非常に勉強になります。
GitHub で .NET Core の完全な実装を読むことができます。
難しく見えるかもしれませんが、単純なもの、きになるものから読んでいくといいと思います。 また、簡単そうなメソッドを自分で書いてみるのも理解するには効果がありました。
LINQ を書く際に気をつけることはこれがすべてではありませんが、ドキュメントやコードをきちんと読んだり、信頼できる先輩にアドバイスをもらったりしながらだんだんと身についていくものだと思います。

あと、 ReSharper などのツールを入れると multiple enumeration の注意を出してくれたりもします。
（ReSharper は他にもいろいろなことを教えてくれる素晴らしい先生になるのでめちゃくちゃおすすめです）

## (おまけ) 記事を書いたきっかけ

もともと微妙なコードをちょくちょく見かけていて、 LINQ ってそんなに難しいのかなーと思っていたのですが、 twitter で

[C#で Linq を使うより Python の方が 2 倍速かったのでベンチマークをしてみた - Qiita](https://qiita.com/yniji/items/6585011633289a257888)

という記事が回ってきました。

公開から短時間でいいねが複数ついていたことから、ほんとうは速くシンプルに書けるにもかかわらず、 LINQ が遅いと判断してしまう人は多いのではないかと思い、 急いで記事を書いている次第です (そもそもこのブログ自体そんなに見られてないのでどの程度効果があるかは疑問ですが)。

この記事の具体的な内容についてはもう十分他の方が指摘などされていると思いますので、ここでは細かく言及しません。 ただ、もし初心者の方が読まれる場合には下記の点だけは頭においてほしいです。

1. (意図的にそうしているとは思いませんが、結果として) 検証用のコードが非常に遅くなるように書かれています。 検証用のコードを改善することでだいぶ速い結果になる、という記事がすでにあります。GroupBy が遅いように書かれていますが、それよりも 無駄な ToList 何度も呼んでいるめにループの回数が増えてしまっていることのほうがはるかに大きな問題です。C# の Linq が python の２倍遅い、は嘘 - Qiita
2. `Span<T>` に関しては用途が違うように思います。 Qiita の記事とは全く無関係ですが、 日本語で読める `Span<T>` の記事としては [Span<T>構造体 - C# によるプログラミング入門 | ++C++; // 未確認飛行 C](http://ufcpp.net/study/csharp/resource/span/) がとても参考になります。
3. 実際には、LINQ に限らず .NET のパフォーマンスの改善や新機能の開発に多くの優秀なエンジニアが取り組んでいます。また、明らかに遅かったり問題があり、改善方法があることが本当にわかっているなら、 issue をあげたり、プルリクエストを送ってみたりする手段は誰にでも開かれています。

BenchmarkDotnet を使って LINQ の部分のベンチマークをとってみたところ、標準の LINQ メソッドだけで 3 倍以上高速になりました。

SlowLinq が Qiita の元記事、 NormalLinq がそれを書き直したもの、 UseGroupSum が GroupBy を使わないものです。

| Method | Mean | Error | Gen 0 | Gen 1 | Gen 2 | Allocated |
| ----------- | --------- | ----- | ---------- | --------- | -------- | ----------- |
| SlowLinq | 321.59 ms | NA | 12400.0000 | 6200.0000 | 800.0000 | 78916.81 KB |
| NormalLinq | 85.77 ms | NA | 1400.0000 | 600.0000 | - | 8415.32 KB |
| UseGroupSum | 62.12 ms | NA | - | - | - | 147.43 KB |

今からできる、速くシンプルに LINQ を書くためのコツ 3 個

<h1>LINQ で指定したキーだけ使って Distinct, Except とかする</h1>
たとえばこんなてきとうなクラスがあったとして
<pre><code class="hljs language-csharp">public class MyClass
{
 public int Id { get; set; }
 public double Value { get; set; }
}
</code></pre>
Id だけを見て distinct とかしたい (けど結果は Value もほしいし、Id が重複した場合に Value は順番に依存 (最初に見つかったもの) で構わない) とかいう場合のはなしです。 最近ちょっと似たようなの書くことがあったのでメモ IEqualityComparer 書けばできますが、もうちょっとぱぱっと書きたくて。。。
<h2>Distinct</h2>
<pre><code class="hljs language-csharp">public static IEnumerable&#x3C;TItem> Distinct&#x3C;TItem, TKey>(this IEnumerable&#x3C;TItem> source, Func&#x3C;TItem, TKey> keySelector)
{
 IEnumerable&#x3C;TItem> Enumerate()
 {
 var set = new HashSet&#x3C;TKey>();
 foreach (var item in source)
 if (set.Add(keySelector(item))) yield return item;
 }

 if (source == null)
 throw new ArgumentNullException(nameof(source));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var data = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 1, Value = 0.5 },
};

// {Id = 1, Value = 1.0}, {Id = 2, Value = 2.0}
var result = data.Distinct(x => x.Id);
</code></pre>
<h2>Except</h2>
<pre><code class="hljs language-csharp">public static IEnumerable&#x3C;TItem> Except&#x3C;TItem, TKey>(this IEnumerable&#x3C;TItem> first, IEnumerable&#x3C;TItem> second, Func&#x3C;TItem, TKey> keySelector)
{
 IEnumerable&#x3C;TItem> Enumerate()
 {
 var set = new HashSet&#x3C;TKey>(second.Select(keySelector));
 foreach (var item in first)
 if (set.Add(keySelector(item))) yield return item;
 }

 if (first == null)
 throw new ArgumentNullException(nameof(first));

 if (second == null)
 throw new ArgumentNullException(nameof(second));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var first = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 3, Value = 3.0 },
};

var second = new []
{
 new MyClass { Id = 1, Value = 100.0 }
};

// {Id = 2, Value = 2.0}, {Id = 3, Value = 3.0}
var result = first.Except(second, x => x.Id);
</code></pre>
<h2>Union</h2>
<pre><code class="hljs language-csharp">public static IEnumerable&#x3C;TItem> Union&#x3C;TItem, TKey>(this IEnumerable&#x3C;TItem> first, IEnumerable&#x3C;TItem> second, Func&#x3C;TItem, TKey> keySelector)
{
 IEnumerable&#x3C;TItem> Enumerate()
 {
 var set = new HashSet&#x3C;TKey>();
 foreach (var item in first)
 if (set.Add(keySelector(item))) yield return item;

 foreach (var item in second)
 if (set.Add(keySelector(item))) yield return item;
 }

 if (first == null)
 throw new ArgumentNullException(nameof(first));

 if (second == null)
 throw new ArgumentNullException(nameof(second));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var first = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 3, Value = 3.0 },
};

var second = new []
{
 new MyClass { Id = 1, Value = 100.0 },
 new MyClass { Id = 4, Value = 400.0 },
};

// {Id = 1, Value = 1.0}, {Id = 2, Value = 2.0}, {Id = 3, Value = 3.0}, {Id = 4, Value = 400.0}
var result = first.Union(second, x => x.Id);
</code></pre>
<h2>Intersect</h2>
<pre><code class="hljs language-csharp">public static IEnumerable&#x3C;TItem> Intersect&#x3C;TItem, TKey>(this IEnumerable&#x3C;TItem> first, IEnumerable&#x3C;TItem> second, Func&#x3C;TItem, TKey> keySelector)
{
 IEnumerable&#x3C;TItem> Enumerate()
 {
 var set = new HashSet&#x3C;TKey>(second.Select(keySelector));

 foreach (var item in first)
 if (!set.Add(keySelector(item))) yield return item;
 }

 if (first == null)
 throw new ArgumentNullException(nameof(first));

 if (second == null)
 throw new ArgumentNullException(nameof(second));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var first = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 3, Value = 3.0 },
};

var second = new []
{
 new MyClass { Id = 1, Value = 100.0 },
 new MyClass { Id = 4, Value = 400.0 },
};

// {Id = 1, Value = 1.0}
var result = first.Intersect(second, x => x.Id);
</code></pre>

# LINQ で指定したキーだけ使って Distinct, Except とかする

たとえばこんなてきとうなクラスがあったとして

```csharp
public class MyClass
{
 public int Id { get; set; }
 public double Value { get; set; }
}
```

Id だけを見て distinct とかしたい (けど結果は Value もほしいし、Id が重複した場合に Value は順番に依存 (最初に見つかったもの) で構わない) とかいう場合のはなしです。 最近ちょっと似たようなの書くことがあったのでメモ IEqualityComparer 書けばできますが、もうちょっとぱぱっと書きたくて。。。

## Distinct

```csharp
public static IEnumerable<TItem> Distinct<TItem, TKey>(this IEnumerable<TItem> source, Func<TItem, TKey> keySelector)
{
 IEnumerable<TItem> Enumerate()
 {
 var set = new HashSet<TKey>();
 foreach (var item in source)
 if (set.Add(keySelector(item))) yield return item;
 }

 if (source == null)
 throw new ArgumentNullException(nameof(source));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var data = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 1, Value = 0.5 },
};

// {Id = 1, Value = 1.0}, {Id = 2, Value = 2.0}
var result = data.Distinct(x => x.Id);
```

## Except

```csharp
public static IEnumerable<TItem> Except<TItem, TKey>(this IEnumerable<TItem> first, IEnumerable<TItem> second, Func<TItem, TKey> keySelector)
{
 IEnumerable<TItem> Enumerate()
 {
 var set = new HashSet<TKey>(second.Select(keySelector));
 foreach (var item in first)
 if (set.Add(keySelector(item))) yield return item;
 }

 if (first == null)
 throw new ArgumentNullException(nameof(first));

 if (second == null)
 throw new ArgumentNullException(nameof(second));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var first = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 3, Value = 3.0 },
};

var second = new []
{
 new MyClass { Id = 1, Value = 100.0 }
};

// {Id = 2, Value = 2.0}, {Id = 3, Value = 3.0}
var result = first.Except(second, x => x.Id);
```

## Union

```csharp
public static IEnumerable<TItem> Union<TItem, TKey>(this IEnumerable<TItem> first, IEnumerable<TItem> second, Func<TItem, TKey> keySelector)
{
 IEnumerable<TItem> Enumerate()
 {
 var set = new HashSet<TKey>();
 foreach (var item in first)
 if (set.Add(keySelector(item))) yield return item;

 foreach (var item in second)
 if (set.Add(keySelector(item))) yield return item;
 }

 if (first == null)
 throw new ArgumentNullException(nameof(first));

 if (second == null)
 throw new ArgumentNullException(nameof(second));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var first = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 3, Value = 3.0 },
};

var second = new []
{
 new MyClass { Id = 1, Value = 100.0 },
 new MyClass { Id = 4, Value = 400.0 },
};

// {Id = 1, Value = 1.0}, {Id = 2, Value = 2.0}, {Id = 3, Value = 3.0}, {Id = 4, Value = 400.0}
var result = first.Union(second, x => x.Id);
```

## Intersect

```csharp
public static IEnumerable<TItem> Intersect<TItem, TKey>(this IEnumerable<TItem> first, IEnumerable<TItem> second, Func<TItem, TKey> keySelector)
{
 IEnumerable<TItem> Enumerate()
 {
 var set = new HashSet<TKey>(second.Select(keySelector));

 foreach (var item in first)
 if (!set.Add(keySelector(item))) yield return item;
 }

 if (first == null)
 throw new ArgumentNullException(nameof(first));

 if (second == null)
 throw new ArgumentNullException(nameof(second));

 if (keySelector == null)
 throw new ArgumentNullException(nameof(keySelector));

 return Enumerate();
}
var first = new []
{
 new MyClass { Id = 1, Value = 1.0 },
 new MyClass { Id = 2, Value = 2.0 },
 new MyClass { Id = 3, Value = 3.0 },
};

var second = new []
{
 new MyClass { Id = 1, Value = 100.0 },
 new MyClass { Id = 4, Value = 400.0 },
};

// {Id = 1, Value = 1.0}
var result = first.Intersect(second, x => x.Id);
```

LINQ で指定したキーだけ使って Distinct, Except とかする

<h1>Utf8Json で JSONP を書く</h1>
Utf8Json.JSONP というライブラリを作りました。 ざっくりしたライブラリの紹介と、どうやって実装したかのメモです。
<h2>簡単な紹介</h2>
nuget でインストールできます。
<a href="https://www.nuget.org/packages/Utf8Json.Jsonp/">NuGet Gallery | Utf8Json.Jsonp 1.1.0</a>
この nuget パッケージを入れると、 <code>Utf8Json</code> の名前空間に <code>Jsonp</code> というクラスが追加されます。
これが JSONP 版の JsonSerializer です。
使いごこちは <code>JsonSerializer</code> と同じになるようにしてあります。 QuickStart にも載せたのですが、こんな感じでかけます。
<pre><code class="hljs language-csharp">var p = new Person { Age = 99, Name = "foobar" };
var callback = "callbackFunc";

// result: callbackFunc({"Age":99,"Name":"foobar"});

// obj -> byte[]
byte[] bytes = Jsonp.Serialize(callback, p);

// write to stream
using (var stream = new MemoryStream())
{
 Jsonp.Serialize(stream, callback, p);
}
</code></pre>
<a href="https://github.com/wipiano/Utf8Json.Jsonp">ソースはこちら</a>。
<h3>対応してないもの</h3>
とりあえず仕事ですぐに使いたくて週末にざざっと作ったので最低限の機能にしています。
落ち着いたら対応していく予定です。
<ul>
<li>型なしのシリアライズにまだ対応していません</li>
<li>ASP.NET Core への組み込みもまだです(仕事では webforms だったので。。。。。。。)</li>
</ul>
<h2>作った目的</h2>
ちょうど仕事で Utf8Json への置換えを進めていて、 JSONP に対応してる API どうしよう・・・って考えたのがきっかけです。 せっかく Utf8Json で超高速な JSON シリアライズができるのに、 JSONP のために文字列とか byte 配列の結合はやりたくなかった。
<h2>実装</h2>
<h3>Newtonsoft.Json による JSONP の書き出し</h3>
まず Utf8Json 置き換え前のコードはこんな感じでした。 シンプルですがあまり速くなさそうです。
<pre><code class="hljs language-csharp">string json = Newtonsoft.Json.JsonConvert.SerializeObject(obj);
string jsonp = string.Format("{0}({1})", callback, obj);
</code></pre>
<h3>Utf8Json による JSONP の書き出し</h3>
で、 Utf8Json に置き換えて最初にやった実装がだいたいこんなかんじ。
<pre><code class="hljs language-csharp">// json と callback の文字列をそれぞれ byte[] に変換
byte[] jsonBytes = Utf8Json.JsonSerializer.Serialize(obj);
byte[] callbackBytes = Encoding.UTF8.GetBytes(callback);

// 結果の byte[] を作る
int byteCount = jsonBytes.Length + callbackBytes.Length + 2;
var jsonpBytes = new byte[byteCount];

// コピーしていく
Array.Copy(callbackBytes, 0, jsonpBytes, 0, callbackBytes.Length);
jsonpBytes[callbackBytes.Length] = (byte) '(';
Array.Copy(jsonBytes, 0, jsonpBytes, callbackBytes.Length + 1, jsonBytes.Length);
jsonpBytes[byteCount - 1] = (byte) ')';
</code></pre>
Utf8Json を使っているのでなんとなく速そうに見えますが、 <code>byte[]</code> を 3 つもつくっています。そしてこのあとさらに stream に書き込んだりするのです。これは遅い。
utf8json の <code>SerializeUnsafe()</code> を使えば多少は良くなりそうですがそれにしても完璧ではなさそうです。
<h3>Utf8Json の primitive API の利用</h3>
配列のコピーをなくして、そのまま JSONP の形になっている byte[] がとれればいちばんよいです。
で、それをやるには Primitive API として公開されている JsonWriter を使って、 シリアライザが内部で持っているバッファに直接書き込んじゃうのが簡単そうでした。
単純にやればとても簡単で、まずやったのはこんな実装でした。 v1.0.0 の実装はこれです。
<pre><code class="hljs language-csharp">public static byte[] Serialize&#x3C;T>(string callback, T value, IJsonFormatterResolver resolver)
{
 // MemoryPool, BufferPool は自分で用意する必要があった
 var writer = new JsonWriter(MemoryPool.GetBuffer());

 // callback の文字列と ( を書く
 writer.WriteRaw(Encoding.UTF8.GetBytes(callback));
 writer.WriteRaw((byte) '(');

 // Utf8Json の API をつかって json を書く
 Utf8Json.JsonSerializer.Serialize(ref writer, value, resolver);

 // ) を書く
 writer.WriteRaw((byte) ')');

 return writer.ToUtf8ByteArray();
}
</code></pre>
<h3>callback 文字列のシリアライズでの配列確保を避ける</h3>
これで満足していたのですが、さっきのコードのこの部分
<pre><code class="hljs language-csharp">// callback の文字列と ( を書く
writer.WriteRaw(Encoding.UTF8.GetBytes(callback));
</code></pre>
これが気になりはじめました。
これだと callback を <code>byte[]</code> に変換するためだけに新しく配列を作ってしまいますし、それを <code>JsonWriter</code> 内部の配列にコピーしないといけません。
最初の実装とそこまで違うの？という感じです。
で、 <code>GetBytes()</code> には任意の配列に書けるオーバーロードがあるのでそれを使ってこんなふうにしました。 すこし無理やりな実装ですが、これで配列が作られるのを防ぎます。
<pre><code class="hljs language-csharp">public static byte[] Serialize&#x3C;T>(string callback, T value, IJsonFormatterResolver resolver)
{
 // MemoryPool, BufferPool は自分で用意する必要があった
 var writer = new JsonWriter(MemoryPool.GetBuffer());

 // writer の内部バッファを取得する
 ArraySegment&#x3C;byte> buffer = writer.GetBuffer();

 // バッファに callback の文字列を書いて、その分だけバッファの現在位置を進めてあげる
 // ここがずれると大変なので、渡すのが byte[] でいい時は WriteRaw() とかをつかうのが良さそう。
 var filledCount = Encoding.UTF8.GetBytes(callback, 0, callback.Length, buffer.Array, buffer.Count);
 writer.AdvanceOffset(filledCount);

 writer.WriteRaw((byte) '(');

 // ( を書く
 writer.WriteRaw((byte) '(');

 // Utf8Json の API をつかって json を書く
 Utf8Json.JsonSerializer.Serialize(ref writer, value, resolver);

 // ) を書く
 writer.WriteRaw((byte) ')');

 return writer.ToUtf8ByteArray();
}
</code></pre>
簡単なベンチマークをとってみたらかなり速くなってました。
<table>
<thead>
<tr>
<th>Method</th>
<th>Mean</th>
<th>Error</th>
<th>StdDev</th>
<th>Gen 0</th>
<th>Allocated</th>
</tr>
</thead>
<tbody>
<tr>
<td>OldVersion</td>
<td>205.1 ns</td>
<td>3.017 ns</td>
<td>3.816 ns</td>
<td>0.0608</td>
<td>96 B</td>
</tr>
<tr>
<td>NewVersion</td>
<td>159.0 ns</td>
<td>2.347 ns</td>
<td>2.196 ns</td>
<td>0.0405</td>
<td>64 B</td>
</tr>
</tbody>
</table>
<h2>おまけ: SerializeUnsafe についての補足</h2>
Utf8Json の API に <code>SerializeUnsafe()</code> というメソッドがあります。 (もちろん Jsonp でもサポートしてます)
このメソッドは何が unsafe かというと、スレッドごとに一個しかないシリアライズ用のバッファをそのまま返してきます。
つまり、結果を受け取ったらすぐに使ってしまわないと、他のオブジェクトをシリアライズした場合に書き換えられてしまう可能性があるということです。
unsafe でない API はこれを避けるために、新しく <code>byte[]</code> を作って返してくれます。
<h3>どんなときに使うと良いか</h3>
たとえば結果をすぐに使って捨ててしまう場合 (たとえば stream に書くとか) の場合は <code>SerializeUnsafe()</code> をつかったほうがお得です。
逆に結果を引き回したり、スレッドをまたいで共有したり、複数のオブジェクトをシリアライズしてあとでまとめて何かする、という時には使えません。
実際、今回も stream に書き込みをする API はこんな感じで実装していますが、これで安全に速く動きます。
この API は本家の Utf8Json にもあるものなので、stream に書いてしまう場合はこれを呼んでもらえれば大丈夫だと思います。
<pre><code class="hljs language-csharp">public static void Serialize&#x3C;T>(Stream stream, string callback, T value, IJsonFormatterResolver resolver)
{
 var buffer = SerializeUnsafe(callback, value, resolver);
 stream.Write(buffer.Array, buffer.Offset, buffer.Count);
}
</code></pre>

# Utf8Json で JSONP を書く

Utf8Json.JSONP というライブラリを作りました。 ざっくりしたライブラリの紹介と、どうやって実装したかのメモです。

## 簡単な紹介

nuget でインストールできます。

[NuGet Gallery | Utf8Json.Jsonp 1.1.0](https://www.nuget.org/packages/Utf8Json.Jsonp/)

この nuget パッケージを入れると、 `Utf8Json` の名前空間に `Jsonp` というクラスが追加されます。
これが JSONP 版の JsonSerializer です。

使いごこちは `JsonSerializer` と同じになるようにしてあります。 QuickStart にも載せたのですが、こんな感じでかけます。

```csharp
var p = new Person { Age = 99, Name = "foobar" };
var callback = "callbackFunc";

// result: callbackFunc({"Age":99,"Name":"foobar"});

// obj -> byte[]
byte[] bytes = Jsonp.Serialize(callback, p);

// write to stream
using (var stream = new MemoryStream())
{
 Jsonp.Serialize(stream, callback, p);
}
```

[ソースはこちら](https://github.com/wipiano/Utf8Json.Jsonp)。

### 対応してないもの

とりあえず仕事ですぐに使いたくて週末にざざっと作ったので最低限の機能にしています。
落ち着いたら対応していく予定です。

- 型なしのシリアライズにまだ対応していません
- ASP.NET Core への組み込みもまだです(仕事では webforms だったので。。。。。。。)


## 作った目的

ちょうど仕事で Utf8Json への置換えを進めていて、 JSONP に対応してる API どうしよう・・・って考えたのがきっかけです。 せっかく Utf8Json で超高速な JSON シリアライズができるのに、 JSONP のために文字列とか byte 配列の結合はやりたくなかった。

## 実装

### Newtonsoft.Json による JSONP の書き出し

まず Utf8Json 置き換え前のコードはこんな感じでした。 シンプルですがあまり速くなさそうです。

```csharp
string json = Newtonsoft.Json.JsonConvert.SerializeObject(obj);
string jsonp = string.Format("{0}({1})", callback, obj);
```

### Utf8Json による JSONP の書き出し

で、 Utf8Json に置き換えて最初にやった実装がだいたいこんなかんじ。

```csharp
// json と callback の文字列をそれぞれ byte[] に変換
byte[] jsonBytes = Utf8Json.JsonSerializer.Serialize(obj);
byte[] callbackBytes = Encoding.UTF8.GetBytes(callback);

// 結果の byte[] を作る
int byteCount = jsonBytes.Length + callbackBytes.Length + 2;
var jsonpBytes = new byte[byteCount];

// コピーしていく
Array.Copy(callbackBytes, 0, jsonpBytes, 0, callbackBytes.Length);
jsonpBytes[callbackBytes.Length] = (byte) '(';
Array.Copy(jsonBytes, 0, jsonpBytes, callbackBytes.Length + 1, jsonBytes.Length);
jsonpBytes[byteCount - 1] = (byte) ')';
```

Utf8Json を使っているのでなんとなく速そうに見えますが、 `byte[]` を 3 つもつくっています。そしてこのあとさらに stream に書き込んだりするのです。これは遅い。
utf8json の `SerializeUnsafe()` を使えば多少は良くなりそうですがそれにしても完璧ではなさそうです。

### Utf8Json の primitive API の利用

配列のコピーをなくして、そのまま JSONP の形になっている byte[] がとれればいちばんよいです。
で、それをやるには Primitive API として公開されている JsonWriter を使って、 シリアライザが内部で持っているバッファに直接書き込んじゃうのが簡単そうでした。

単純にやればとても簡単で、まずやったのはこんな実装でした。 v1.0.0 の実装はこれです。

```csharp
public static byte[] Serialize<T>(string callback, T value, IJsonFormatterResolver resolver)
{
 // MemoryPool, BufferPool は自分で用意する必要があった
 var writer = new JsonWriter(MemoryPool.GetBuffer());

 // callback の文字列と ( を書く
 writer.WriteRaw(Encoding.UTF8.GetBytes(callback));
 writer.WriteRaw((byte) '(');

 // Utf8Json の API をつかって json を書く
 Utf8Json.JsonSerializer.Serialize(ref writer, value, resolver);

 // ) を書く
 writer.WriteRaw((byte) ')');

 return writer.ToUtf8ByteArray();
}
```

### callback 文字列のシリアライズでの配列確保を避ける

これで満足していたのですが、さっきのコードのこの部分

```csharp
// callback の文字列と ( を書く
writer.WriteRaw(Encoding.UTF8.GetBytes(callback));
```

これが気になりはじめました。
これだと callback を `byte[]` に変換するためだけに新しく配列を作ってしまいますし、それを `JsonWriter` 内部の配列にコピーしないといけません。
最初の実装とそこまで違うの？という感じです。

で、 `GetBytes()` には任意の配列に書けるオーバーロードがあるのでそれを使ってこんなふうにしました。 すこし無理やりな実装ですが、これで配列が作られるのを防ぎます。

```csharp
public static byte[] Serialize<T>(string callback, T value, IJsonFormatterResolver resolver)
{
 // MemoryPool, BufferPool は自分で用意する必要があった
 var writer = new JsonWriter(MemoryPool.GetBuffer());

 // writer の内部バッファを取得する
 ArraySegment<byte> buffer = writer.GetBuffer();

 // バッファに callback の文字列を書いて、その分だけバッファの現在位置を進めてあげる
 // ここがずれると大変なので、渡すのが byte[] でいい時は WriteRaw() とかをつかうのが良さそう。
 var filledCount = Encoding.UTF8.GetBytes(callback, 0, callback.Length, buffer.Array, buffer.Count);
 writer.AdvanceOffset(filledCount);

 writer.WriteRaw((byte) '(');

 // ( を書く
 writer.WriteRaw((byte) '(');

 // Utf8Json の API をつかって json を書く
 Utf8Json.JsonSerializer.Serialize(ref writer, value, resolver);

 // ) を書く
 writer.WriteRaw((byte) ')');

 return writer.ToUtf8ByteArray();
}
```

簡単なベンチマークをとってみたらかなり速くなってました。


|Method|Mean|Error|StdDev|Gen 0|Allocated|
|--|--|--|--|--|--|
|OldVersion|205.1 ns|3.017 ns|3.816 ns|0.0608|96 B|
|NewVersion|159.0 ns|2.347 ns|2.196 ns|0.0405|64 B|

## おまけ: SerializeUnsafe についての補足

Utf8Json の API に `SerializeUnsafe()` というメソッドがあります。 (もちろん Jsonp でもサポートしてます)
このメソッドは何が unsafe かというと、スレッドごとに一個しかないシリアライズ用のバッファをそのまま返してきます。
つまり、結果を受け取ったらすぐに使ってしまわないと、他のオブジェクトをシリアライズした場合に書き換えられてしまう可能性があるということです。
unsafe でない API はこれを避けるために、新しく `byte[]` を作って返してくれます。

### どんなときに使うと良いか

たとえば結果をすぐに使って捨ててしまう場合 (たとえば stream に書くとか) の場合は `SerializeUnsafe()` をつかったほうがお得です。
逆に結果を引き回したり、スレッドをまたいで共有したり、複数のオブジェクトをシリアライズしてあとでまとめて何かする、という時には使えません。

実際、今回も stream に書き込みをする API はこんな感じで実装していますが、これで安全に速く動きます。
この API は本家の Utf8Json にもあるものなので、stream に書いてしまう場合はこれを呼んでもらえれば大丈夫だと思います。

```csharp
public static void Serialize<T>(Stream stream, string callback, T value, IJsonFormatterResolver resolver)
{
 var buffer = SerializeUnsafe(callback, value, resolver);
 stream.Write(buffer.Array, buffer.Offset, buffer.Count);
}
```

Utf8Json で JSONP を書く

# C# の ref まとめ

C#7.2 までの参照渡し関係のまとめです。

C# 7 系で参照渡しの扱いが強化されて種類も増えました。 上手につかうとサイズの大きい値型のコピーを避けられるのでまとめてみました。 動作をきちんと理解するために C# to C# の変換をしたコードや IL をのせています。

## 予備知識 - defensive copy, readonly struct

### defensive copy - 防衛的なコピー

`readonly` 指定された値型は値が変化しないことを保証するために、コンパイラが値を防衛的にコピーしている場合がある。

defensive copy が発生するのは下記の場合に、後述する `readonly struct` ではないふつうの `struct` を使用しているとき

- readonly フィールドとして構造体を持っている場合
- readonly な参照渡しで構造体を返すとき

#### 例

こんな構造体があった場合を考える。

```csharp
public struct Point
{
 public double X;
 public double Y;

 // フィールドを書き換えるメソッド
 public void Set(double x, double y)
 {
 X = x;
 Y = y;
 }
}
```

##### readonly フィールドでない場合

たとえば、このようなクラスでは防御的コピーは発生しない（readonly でないので、構造体のフィールドを書き換えることに制限はない）

```csharp
public static class MyClass
{
 // readonly でないフィールド
 private static Point s_origin = default;

 public static void Sample()
 {
 // フィールド書き換え
 s_origin.Set(1, 1);

 // 実際に書き換わっている
 Console.WriteLine($"X: {s_origin.X}, Y: {s_origin.Y}");
 }
}
```

IL を見ると、こんな感じ

```
MyClass.Sample:
IL_0000: nop

; s_origin の「アドレス」をスタックに push
IL_0001: ldsflda MyClass.s_origin

; set メソッドの呼び出し
IL_0006: ldc.r8 00 00 00 00 00 00 F0 3F
IL_000F: ldc.r8 00 00 00 00 00 00 F0 3F
IL_0018: call Point.Set
IL_001D: nop 
```

##### readonly フィールドの場合

```csharp
public static class MyClass
{
 // 原点の座標を何度も使うので readonly フィールドにもつ
 private static readonly Point s_origin = default;

 public static void Sample()
 {
 // 構造体のフィールドは readonly を受け継ぐので書き換えできない
 // s_origin.X = 1;

 // フィールドを書き換えるかもしれないメソッドは呼べるように見える
 s_origin.Set(1, 1);

 // 実際には書き換わっていない
 Console.WriteLine($"X: {s_origin.X}, Y: {s_origin.Y}");
 }
}
```

`s_origin.Set()` メソッドを呼んでもフィールドが書き換わっていないが、 これは（フィールドを変更しているかもしれない）メソッド呼び出しを許容しつつ、readonly であることを保証するために、いったん `s_origin` をコピーしてから、そのコピーに対してメソッドを呼ぶため。

「メソッドの中でなにも書き換えていない」ことは呼び出し側から知るすべがないので、実際にコピーが必要かどうかにかかわらず常にコピーが発生する。 readonly なフィールドや readonly な参照 (in 引数) を使用するときは注意が必要。

IL をみると、ローカル変数に値をコピーしてからメソッドを読んでいる

```
MyClass.Sample:
IL_0000: nop
; 値をローカル変数にコピー
IL_0001: ldsfld MyClass.s_origin
IL_0006: stloc.0

; ローカル変数のアドレスをスタックに push
IL_0007: ldloca.s 00

; ローカル変数にたいして Set() を呼ぶ
IL_0009: ldc.r8 00 00 00 00 00 00 F0 3F
IL_0012: ldc.r8 00 00 00 00 00 00 F0 3F
IL_001B: call Point.Set
IL_0020: nop 
```

### readonly struct

防衛的なコピーは、下記のようにすべてのフィールドを readonly にしていても発生する。

```csharp
struct NoReadOnlyPoint
{
 // X, Y は readonly
 public readonly double X;
 public readonly double Y;

 // フィールドや this の書き換えを行うメソッドは持たないが、
 // 呼び出し側からはフィールドの書き換えを行っていないことを知るすべがないため、
 // readonly な NoReadOnlyPoint のインスタンスに対して Hoge() を呼ぶと、常に defensive copy が発生する
 public void Hoge()
 {
 // ...
 }
}
```

下記のように `readonly struct` とすることによって、フィールドの書き換えが起こらないことを保証でき、 defensive copy を避けられる

```csharp
readonly struct ReadOnlyPoint
{
 // readonly なフィールドのみ許容される
 // get-only プロパティも、結局 readonly フィールドを生成するので許容
 public readonly double X;
 public readonly double Y;

 // フィールドや this の書き換えを行うメソッドは持てないので、
 // 呼び出し側で defensive copy の必要がない
 public void Hoge()
 {
 // ...
 }
}
```

### 呼び出し例

```csharp
public static class MyClass
{
 // 原点の座標を何度も使うので readonly フィールドにもつ
 private static readonly NoReadOnlyPoint s_noReadonlyOrigin = default;
 private static readonly ReadOnlyPoint s_readonlyOrigin = default;

 public static void Sample()
 {
 // 防衛的なコピーが発生
 s_noReadonlyOrigin.Hoge();

 // 防衛的なコピーが発生しない
 s_readonlyOrigin.Hoge();
 }
}
```

#### IL

```
MyClass.Sample:
IL_0000: nop

// readonly struct でない場合はコピーが発生
IL_0001: ldsfld MyClass.s_noReadonlyOrigin
IL_0006: stloc.0
IL_0007: ldloca.s 00
IL_0009: call NoReadOnlyPoint.Hoge
IL_000E: nop

// readonly struct の場合はコピーが発生しない
IL_000F: ldsflda MyClass.s_readonlyOrigin
IL_0014: call ReadOnlyPoint.Hoge
IL_0019: nop
IL_001A: ret 
```

#### 生成される C# コード

`readonly struct` にした構造体には、コンパイラが [IsReadOnly] 属性をつける

```csharp
[IsReadOnly]
private struct ReadOnlyPoint
{
 public readonly double X;
 public readonly double Y;
 public void Hoge()
 {
 }
}
```

この属性によって readonly struct かどうかの判定をおこなうようだ

## 参照渡しの種類一覧

|種類|使う場所|書き換え|C#のバージョン|
|--|--|--|--|
|ref parameters|引数|o|1.0?|
|out parameters|引数|o|1.0?|
|in parameters|引数|x|7.2|
|ref returns|戻り値|o|7.0|
|ref returns (readonly)|戻り値|x|7.2|
|ref locals|ローカル変数|o|7.0|
|ref locals (readonly)|ローカル変数|x|7.2|

## 参照引数についての詳細

### ref parameters

読み書き両方できる参照渡しの引数。 渡す前にかならず初期化が必要

x と y を交換するメソッドの例:

```csharp
void Main()
{
 // 必ず初期化しておく
 int x = 1;
 int y = 2;

 Swap(ref x, ref y); // x: 2, y: 1
}

public static void Swap<T>(ref T x, ref T y)
{
 T tmp = x;
 x = y;
 y = tmp;
}
```

### out parameters

出力用の参照引数。 渡す前に初期化が不要で、 C# 7 では out-var で変数の宣言と同時に受け取れる

```csharp
void Main()
{
 var list = new List<int>() { 1, 2, 3, 4 };

 // 出力引数のうけとり
 // C#7 からは 受けとりと同時に変数の宣言が可能
 if (TryGetAt(list, 1, out var elem))
 {
 Console.WriteLine(elem);
 }
 else
 {
 Console.WriteLine("not found");
 }
}

// IList<T> の指定したインデックスの値を返す
private static bool TryGetAt<T>(IList<T> list, int index, out T elem)
{
 if (list.Count > index)
 {
 // out 引数に結果を入れる
 elem = list[index];
 return true;
 }
 else
 {
 // out 引数は必ず初期化しなければならない
 elem = default;
 return false;
 }
}
```

### in parameters

読み取り専用の参照渡し引数。 値渡しで発生する構造体のコピーを避けつつ、 ref で参照渡ししたときの書き換えのリスクもなくす。 ただし、予備知識に書いたとおり、 readonly struct でない値型を受け取ったときに、プロパティやメソッドの呼び出しを行うと無条件にコピーが発生するので注意。

例:

```csharp
using System;

public class Program
{
 static void F(in int x)
 {
 // 読み取り可能
 Console.WriteLine(x);

 // 書き換えようとするとコンパイル エラー
 x = 2;
 }

 // 補足: in 引数はオプションにもできる
 static void G(in int x = 1)
 {
 }

 static void Main()
 {
 int x = 1;

 // ref 引数と違って修飾不要
 F(x);

 // 明示的に in と付けてもいい
 F(in x);

 // リテラルに対しても呼べる
 F(10);

 // 右辺値(式の計算結果)に対しても呼べる
 int y = 2;
 F(x + y);

 // in のオプション引数を省略した呼び出し
 G();
 }
}
```

コンパイル後は結局は ref に変換される

```csharp
using System;
using System.Runtime.CompilerServices;
public class Program
{
 // [IsReadOnly] がついた ref になる
 private static void F([IsReadOnly] ref int x)
 {
 // 読み取り可能
 Console.WriteLine(x);
 }

 private static void G([IsReadOnly] ref int x = 1)
 {
 }

 private static void Main()
 {
 // in で修飾してもしなくても結局ただの ref になる
 int num = 1;
 Program.F(ref num);
 Program.F(ref num);

 // リテラルに対しての呼び出しは ローカル変数が作られて、その参照が渡される
 int num2 = 10;
 Program.F(ref num2);

 // 式の計算結果に対して呼ぶ場合は先に式の計算結果をローカル変数に入れておいて、その参照が渡される
 int num3 = 2;
 num2 = num + num3;
 Program.F(ref num2);

 // オプション引数を省略した場合は、デフォルト値の参照が渡される
 num2 = 1;
 Program.G(ref num2);
 }
}
```

(サンプルコードは[こちら](http://ufcpp.net/study/csharp/sp_ref.html?p=1#in)から引用させていただきました)

### 参照戻り値、参照ローカル変数

C# 7 から、戻り値とローカル変数にも参照渡しが使えるようになった。 C# 7.2 からは readonly な参照を返すこともできる

通常の ref returns では、readonly なフィールドを返すことはできないが， readonly な ref returns では、 readonly なフィールドを返せる。

```csharp
using System;
public class Program
{
 public void Sample()
 {
 var user = new User("hanako");

 // 書き換えできる参照
 ref var mutableId = ref user.MutableId;
 mutableId = Guid.NewGuid();

 // 書き換えできない参照
 ref readonly var immutableId = ref user.ImmutableId;
 // immutableId = Guid.NewGuid(); // 代入できない

 // これは値渡し
 var idValue = user.Id;
 var idValue2 = user.MutableId;
 var idValue3 = user.ImmutableId;
 }
}

public class User
{
 private Guid _id;
 public string Name { get; }

 // これは値渡し
 public Guid Id => _id;

 // 書き換えできる参照を返す
 public ref Guid MutableId => ref _id;

 // readonly な参照を返す
 public ref readonly Guid ImmutableId => ref _id;

 public User(string name)
 {
 _id = Guid.NewGuid();
 Name = name;
 }
}
```

コンパイルすると、 readonly でも readonly でなくてもどちらも同じコードになる (`IsReadOnlyAttribute` がつく)。 ポインタをつかった unsafe コードが生成される。

```csharp
using System;
using System.Diagnostics;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Security;
using System.Security.Permissions;

[assembly: AssemblyVersion("0.0.0.0")]
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
[assembly: SecurityPermission(SecurityAction.RequestMinimum, SkipVerification = true)]
[module: UnverifiableCode]
public class Program
{
 public unsafe void Sample()
 {
 User user = new User("hanako");
 Guid* mutableId = user.MutableId;
 *mutableId = Guid.NewGuid();
 Guid* immutableId = user.ImmutableId;
 Guid id = user.Id;
 Guid guid = *user.MutableId;
 Guid guid2 = *user.ImmutableId;
 }
}
public class User
{
 private Guid _id;

 [DebuggerBrowsable(DebuggerBrowsableState.Never), CompilerGenerated]
 private readonly string <Name>k__BackingField;

 public string Name
 {
 [CompilerGenerated]
 get
 {
 return this.<Name>k__BackingField;
 }
 }

 public Guid Id
 {
 get
 {
 return this._id;
 }
 }

 public unsafe Guid* MutableId
 {
 get
 {
 return ref this._id;
 }
 }

 [IsReadOnly]
 public unsafe Guid* ImmutableId
 {
 [return: IsReadOnly]
 get
 {
 return ref this._id;
 }
 }

 public User(string name)
 {
 this._id = Guid.NewGuid();
 this.<Name>k__BackingField = name;
 }
}
```

## 参考
- [C# 7 Series, Part 6: Read-only structs - Mark Zhou's Tech Blog](https://blogs.msdn.microsoft.com/mazhou/2017/11/21/c-7-series-part-6-read-only-structs/)
- [C# 7 Series, Part 7: Ref Returns - Mark Zhou's Tech Blog](https://blogs.msdn.microsoft.com/mazhou/2017/12/12/c-7-series-part-7-ref-returns/)
- [C# 7 Series, Part 8: “in” Parameters - Mark Zhou's Tech Blog](https://blogs.msdn.microsoft.com/mazhou/2018/01/08/c-7-series-part-8-in-parameters/)
- [参照渡し - C# によるプログラミング入門 | ++C++; // 未確認飛行 C](http://ufcpp.net/study/csharp/sp_ref.html)
- [readonly の注意点 - C# によるプログラミング入門 | ++C++; // 未確認飛行 C](http://ufcpp.net/study/csharp/resource/readonlyness/)
- [What's New in C# 7 - C# Guide | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-7)
- [What's new in C# 7.2 | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-7-2)
- [Reference semantics with value types | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/csharp/reference-semantics-with-value-types)

## 関連: `Span<T>`

- [Span構造体 - C# によるプログラミング入門 | ++C++; // 未確認飛行 C](http://ufcpp.net/study/csharp/resource/span/)
- [ref構造体 - C# によるプログラミング入門 | ++C++; // 未確認飛行 C](http://ufcpp.net/study/csharp/resource/refstruct/)

Cisis - C##

ASP.NET Core 開発者のブログ

新着記事