LoginSignup
0

More than 1 year has passed since last update.

posted at

updated at

System.Diagnostics.Activityのオーバーヘッド

はじめに

ActivitySourceの記事で一通り機能は解説できていたと思うが、この記事では、実際にActivityを有効にしたときのオーバーヘッドを確認してみたいと思う。

テストプログラム

テストプログラムは gistにアップロードしている

ここでは以下のようなベンチマークを実施した。

テスト名 使用クラス 有効 備考
CreateActivityOnly - - new Activity()のオーバーヘッドの計測のため
DiagnosticSource_Disabled DiagnosticSource ×
DiagnosticSource_Enabled DiagnosticSource
ActivitySource_Disabled ActivitySource ×
ActivitySource_None ActivitySource ActivitySamplingResultにNoneを指定
ActivitySource_Propagation ActivitySource ActivitySamplingResultにPropagationDataを指定
ActivitySource_AllData ActivitySource ActivitySamplingResultにAllDataを指定
ActivitySource_AllDataAndRecorded ActivitySource ActivitySamplingResultにAllDataAndRecordedを指定

結果

結果は以下のようになった。


BenchmarkDotNet=v0.12.1, OS=Windows 10.0.18363.1139 (1909/November2018Update/19H2)
Intel Core i7-9700 CPU 3.00GHz, 1 CPU, 8 logical and 8 physical cores
.NET Core SDK=5.0.100
  [Host]   : .NET Core 5.0.0 (CoreCLR 5.0.20.51904, CoreFX 5.0.20.51904), X64 RyuJIT
  ShortRun : .NET Core 5.0.0 (CoreCLR 5.0.20.51904, CoreFX 5.0.20.51904), X64 RyuJIT

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

Method Mean Error StdDev Gen 0 Gen 1 Gen 2 Allocated
CreateActivityOnly 10.6031 ns 1.6297 ns 0.0893 ns 0.0280 - - 176 B
DiagnosticSource_Disabled 0.5074 ns 0.1019 ns 0.0056 ns - - - -
DiagnosticSource_Enabled 533.8810 ns 118.0714 ns 6.4719 ns 0.1135 - - 712 B
ActivitySource_Disabled 14.6574 ns 0.3357 ns 0.0184 ns - - - -
ActivitySource_None 65.7799 ns 3.1931 ns 0.1750 ns - - - -
ActivitySource_Propagation 635.7652 ns 193.5533 ns 10.6093 ns 0.1001 - - 632 B
ActivitySource_AllData 616.2310 ns 10.3009 ns 0.5646 ns 0.1001 - - 632 B
ActivitySource_AllDataAndRecorded 633.3614 ns 208.1648 ns 11.4102 ns 0.1001 - - 632 B

考察

有効無効の差

まず、有効と無効の有無で約500~600nsの差が出ていることは大きな特徴として言えるだろう。
CreateActivityOnly(=newのみ)の結果は10ns程度で、ほとんどコストがかかっていないことから、Activity開始処理の中で様々な属性をセットしていることが起因していると思われる。

ActivitySourceとDiagnosticSourceの比較

また、DiagnosticSourceとActivitySourceで比較した場合、若干DiagnosticSourceの方がオーバーヘッドが少ないように見える。
これは、後述するActivitySamplingResultのチェック等も含まれているためと思われる。
ただし、DiagnosticSource経由で使用する場合は使い勝手が悪いため、この辺りはどちらを優先するかという問題になると思う。

ActivitySamplingResultによる違い

それぞれのフラグを比較すると、ActivitySamplingResult.Noneの時が特別に低い状態になっている。
これは同フラグを指定するとActivityを生成しないという動作をするので、オーバーヘッドがフラグのチェックのみになっているためと思われる。
他のフラグについては、今回計測した範囲では有意な差は無かった。
これは、None以外はActivityを構築するアプリケーションが参考にするフラグなので、内部的な動作にはほぼ影響しないということだろう。
ただし、アプリケーション側ではフラグを見てActivityにデータやイベントを追加するということは十分に考えられるので、無意味なフラグというわけではない。

まとめ

今回Activity自体のオーバーヘッドを測ったが、大きくても一回当たり1usec以下なので、これを気にするかどうかはユーザー次第であることは忘れないでおきたい。
シビアな状況においては、有効と無効の差はかなり大きいので、留意しておきたい。
また、オーバーヘッドが気になる状況でも、ActivitySamplingResultによってある程度軽減はできるため、検討しておくといいと思う。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0