Notices by あじょだよ (azyobuzin@mstdn.maud.io), page 54

Xperia アクションの「Xperia™のゲーム操作パフォーマンスを最適化する」ってやつ、オンにすると確かに変化はあるみたいで、ミリシタのタイミング調整を -2 にすることになった

> static lambdas are emitted as instance methods on a singleton receiver
> delegates invoke dispatch is optimized for instance delegates so it is preferrable to emit lambdas as instance methods even when lambdas do not capture anything
https://github.com/dotnet/roslyn/commit/3de67f36894b8c93431619c256d77cc9cd2e291a?diff=unified#diff-b90f2a5538ff89f48e9be8fb116822baR988

ということで、どうもデリゲート自体が thiscall のほうが速いっぽいぞ

シングルトンになる条件は書いてあるけど、理由が書いてない…… https://github.com/dotnet/roslyn/blob/8d7908c1a0897b4868e4189dae40a3de42664bf2/src/Compilers/CSharp/Portable/Lowering/LambdaRewriter/ClosureKind.cs

ディスクアクセスをするときは時間がかかることを想定してくれこっちは USB2.0 で接続された HDD なんだぞ

状況ですが、 dotnet restore に何分かかるんじゃボケです

@kb10uy
1. static メソッドのデリゲートは作れる
2. String のコンストラクタは InternalCall を経由して、 this が null の状態でインスタンスメソッド Ctor が呼ばれる
ので、 this に null は正常に動作する

@kb10uy とは？

@kb10uy インスタンスメソッドとして定義するという挙動に統一して、もしキャプチャするものがなければ、外部を少し最適化してやろうっていう挙動をしてるって考えね。でも、ものすごい複雑なことを Inline Function でやっていることを考えると、そういうところにコストかけるという判断になりそうな気がするが

@kb10uy それに意味ある？

@kb10uy うーん？

@kb10uy そうならば、何もキャプチャしないときにわざわざシングルトンにする最適化は行わないと思うが
ref: https://mstdn.maud.io/@azyobuzin/100616358956910447

@kb10uy 何もキャプチャしていなくても、外側が static だろうと、 Release だろうと、クラスが作られ、そのインスタンスメソッドのデリゲートが作られる

ラムダ式をデリゲートにするとき、どう頑張っても this は null にならないんだなぁ。なんでだ

親が文字が流れるだけの YouTube を見ていて悲しいよ

初代学長……

よくこんなの考えつくな...

FAX番号だけで複合機が乗っ取られる“Faxploit”脆弱性公表
http://ascii.jp/elem/000/001/728/1728508/

ImmutableArray.Builder、 Count と Capacity が違うと MoveToImmutable で例外吐くけど、 MoveOrCopy みたいなのは入ってないのかなぁ

VS 15.8 のデコンパイル機能、 ILSpy のエンジン使ってるのか

Twitter 英作文どうしよう、英語が書けない

前はあんなにできたのに → それはデレステ公開から1年間ほぼ毎日欠かさずやっていたから