blocks|key|2009231|text|我认为“大量”在大多数用例中都被夸大了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2009232|具有静态构造函数(即使它什么也不做)会由于beforefieldinit+flag的存在/不存在而影响类型初始化时间。当你有一个静态构造函数时，有更严格的计时保证。|offset|length|2009233|对于大多数代码，我建议这并没有太大的不同--但是如果你是紧循环并且访问一个类的静态成员，它可能会。就我个人而言，我不会太担心这一点--如果你怀疑它与你的实际应用程序相关，那么测试它而不是猜测。在这里，微基准很可能会夸大效果。|2009234|值得注意的是，当涉及到类型初始化时，.NET+4+behaves+somewhat+differently+to+previous+versions+-因此任何基准测试都应该真正显示不同的版本，以便具有相关性。|2009235|entityMap|0|LINK|mutability|MUTABLE|url|https://csharpindepth.com/Articles/BeforeFieldInit|1|https://codeblog.jonskeet.uk/2010/01/26/type-initialization-changes-in-net-4-0/^0|0|L|K|0|0|0|P|1D|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

I think &quot;substantial&quot; is an overstatement in most use cases.
Having a static constructor (even if it does nothing) affects type initialization time due to the presence/absence of the <a href="https://csharpindepth.com/Articles/BeforeFieldInit" rel="nofollow noreferrer">beforefieldinit flag</a>. There are stricter guarantees about timing when you have a static constructor.
For most code, I'd suggest this doesn't make much difference - but if you're tight-looping and accessing a static member of a class, it might. Personally I wouldn't worry about it too much - if you have a suspicion that it's relevant in your real application, then test it rather than guessing. Microbenchmarks are very likely to exaggerate the effect here.
It's worth noting that .NET 4 <a href="https://codeblog.jonskeet.uk/2010/01/26/type-initialization-changes-in-net-4-0/" rel="nofollow noreferrer">behaves somewhat differently to previous versions</a> when it comes to type initialization - so any benchmarks should really show the different versions in order to be relevant.

blocks|key|3416859|text|我刚刚复制了他的测试结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3416860|对于调试版本的1000000000次迭代，我得到：|offset|length|style|BOLD|3416861|带有static+constructor|3416862|3.6s的静态类的|unordered-list-item|3416863|4s带有注释掉的static+constructor|3416864|2.9s的相同类，带有带有static构造函数的非静态类(并在迭代之前创建实例)，或者是静态构造函数，或者不是|3416865|3416866|3416867|与发布的+build相同，但也会突出不同之处：|3416868|带静态构造函数的|3416869|静态类:+4046.875ms不带静态构造函数的|3416870|静态类:带静态构造函数的484.375ms|3416871|Instance+:不带静态构造函数的484.375ms|3416872|Instance+:+484.375ms|3416873|3416874|entityMap^0|0|2|2|0|0|0|0|0|0|0|1|3|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1C|8|@]|9|@]|A|$]]|$1|M|3|N|5|L|7|1D|8|@]|9|@]|A|$]]|$1|O|3|P|5|L|7|1E|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1K|8|@]|9|@]|A|$]]|$1|W|3|X|5|L|7|1L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|1M|8|@]|9|@]|A|$]]|$1|10|3|11|5|L|7|1N|8|@]|9|@]|A|$]]|$1|12|3|13|5|L|7|1O|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|16|$]]

Well I've just replicated his test.

For 1000000000 iterations with a DEBUG build I get:

<ul>
<li>4s for his static class with a static
constructor</li>
<li>3.6s same class with commented out static constructor</li>
<li>2.9s with the class non-static (and creating an instance before the
iteration) with either a static
constructor or not</li>
</ul>

The same with a RELEASE build does highlight a difference:

<ul>
<li>Static class with static constructor:
4046.875ms </li>
<li>Static class with no static constructor: 484.375ms</li>
<li>Instance with static constructor:
484.375ms</li>
<li>Instance with no static constructor: 484.375ms</li>
</ul>

blocks|key|523660|text|CLR为静态构造函数的执行提供了非常强大的保证，它承诺在类中的任何方法可以运行之前只调用它们一次。当有多个线程使用该类时，这种保证很难实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|523661|浏览一下SSCLI20的CLR源代码，我发现有相当多的代码专门用于提供这种保证。它维护一个由全局锁保护的运行静态构造函数的列表。一旦它在该列表中获得一个条目，它就会切换到特定于类的锁，以确保没有两个线程可以运行构造函数。对指示构造函数已运行的状态位进行双重检查锁定。提供异常保证的大量难以理解的代码。|523662|好吧，这段代码不是免费的。把它加到cctor本身的执行时间上，你就会看到一些开销。像往常一样，不要让这件事影响你的风格，这也是一个你不想给自己提供的非常好的保证。并在修复之前进行测量。|523663|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The CLR provides a pretty strong guarantee for the execution of static constructors, it promises to call them only once and before any method in the class can run. That guarantee is fairly tricky to implement when there are multiple threads using the class.

Taking a peek at the CLR source code for SSCLI20, I see a fairly large chunk of code dedicated to providing this guarantee. It maintains a list of running static constructors, protected by a global lock. Once it gets an entry in that list, it switches to a class specific lock which ensures no two threads can be running the constructor. Double-checked locking on a status bit that indicates that the constructor was already run. Lots of inscrutable code that provides exception guarantees.

Well, this code doesn't come for free. Add it to the execution time for the cctor itself and you're looking at some overhead. As always, don't let this cramp your style, this guarantee is also a very nice one that you wouldn't want to provide yourself. And measure before you fix.

blocks|key|3416979|text|我刚刚做了一个小测试，以检查向我的一个类添加静态构造函数的影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3416980|我有一个基类，如下所示：|3416981|public+abstract+class+Base
{
++++public+abstract+Task+DoStuffAsync();
}|code-block|syntax|javascript|3416982|问题是，在其中一个实现中，该方法什么也不做，所以我可以设置一个预先完成的任务，然后每次都返回它。|3416983|public+sealed+class+Test1+:+Base
{
++++readonly+Task+_emptyTask;

++++public+Test1()
++++{
++++++++TaskCompletionSource<Object>+source+=+new+TaskCompletionSource<object>();
++++++++source.SetResult(null);
++++++++_emptyTask+=+source.Task;
++++}

++++public+override+Task+DoStuffAsync()
++++{
++++++++return+_emptyTask;
++++}
}|3416984|(另一种选择是按需返回任务，但事实证明此方法总是被调用)|3416985|这个类的对象经常被创建，通常是在循环中。看起来，将_emptyTask设置为静态字段会很有好处，因为它对所有方法都是相同的Task：|offset|length|style|CODE|3416986|public+sealed+class+Test2+:+Base
{
++++static+readonly+Task+_emptyTask;

++++static+Test2()
++++{
++++++++TaskCompletionSource<Object>+source+=+new+TaskCompletionSource<object>();
++++++++source.SetResult(null);
++++++++_emptyTask+=+source.Task;
++++}

++++public+override+Task+DoStuffAsync()
++++{
++++++++return+_emptyTask;
++++}
}|3416987|然后，我想起了静态构造函数和性能的“问题”，在研究了一下(这就是我在这里的原因)后，我决定做一个小的基准测试：|3416988|Stopwatch+sw+=+new+Stopwatch();
List<Int64>+test1list+=+new+List<Int64>(),+test2list+=+new+List<Int64>();

for+(int+j+=+0;+j+<+100;+j%2B%2B)
{
++++sw.Start();
++++for+(int+i+=+0;+i+<+1000000;+i%2B%2B)
++++{
++++++++Test1+t+=+new+Test1();
++++++++if+(!t.DoStuffAsync().IsCompleted)
++++++++++++throw+new+Exception();
++++}
++++sw.Stop();
++++test1list.Add(sw.ElapsedMilliseconds);

++++sw.Reset();
++++sw.Start();
++++for+(int+i+=+0;+i+<+1000000;+i%2B%2B)
++++{
++++++++Test2+t+=+new+Test2();
++++++++if+(!t.DoStuffAsync().IsCompleted)
++++++++++++throw+new+Exception();
++++}
++++sw.Stop();
++++test2list.Add(sw.ElapsedMilliseconds);

++++sw.Reset();
++++GC.Collect();
}

Console.WriteLine("Test+1:+"+%2B+test1list.Average().ToString()+%2B+"ms.");
Console.WriteLine("Test+2:+"+%2B+test2list.Average().ToString()+%2B+"ms.");|3416989|结果非常清楚：|3416990|+Test+1:+53.07+ms.+
+Test+2:+5.03+ms.+
+end|3416991|因此，尽管有一个静态构造函数，但好处大于问题。所以一定要测量。|3416992|entityMap^0|0|0|0|0|0|0|P|A|1P|4|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1A|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1B|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|1C|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|1D|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1E|8|@$Q|1F|R|1G|S|T]|$Q|1H|R|1I|S|T]]|9|@]|A|$]]|$1|U|3|V|5|F|7|1J|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|F|7|1L|8|@]|9|@]|A|$G|H]]|$1|10|3|11|5|6|7|1M|8|@]|9|@]|A|$]]|$1|12|3|13|5|F|7|1N|8|@]|9|@]|A|$G|H]]|$1|14|3|15|5|6|7|1O|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|17|$]]

I just did a small test to check the impact of adding a static constructor to one of my classes.

I have a base class that looks like this:

<pre><code>public abstract class Base
{
 public abstract Task DoStuffAsync();
}
</code></pre>

The problem is, that in one of the implementations that method does nothing, so I can set a pre-made completed task and return it every time.

<pre><code>public sealed class Test1 : Base
{
 readonly Task _emptyTask;

 public Test1()
 {
 TaskCompletionSource&lt;Object&gt; source = new TaskCompletionSource&lt;object&gt;();
 source.SetResult(null);
 _emptyTask = source.Task;
 }

 public override Task DoStuffAsync()
 {
 return _emptyTask;
 }
}
</code></pre>

(Other option is to return the task on demand, but turns out this method is always called)

Objects of this class are created very very often, usually in loops. Looking at it, it looks like setting <code>_emptyTask</code> as a static field would be beneficial since it would be the same <code>Task</code> for all methods:

<pre><code>public sealed class Test2 : Base
{
 static readonly Task _emptyTask;

 static Test2()
 {
 TaskCompletionSource&lt;Object&gt; source = new TaskCompletionSource&lt;object&gt;();
 source.SetResult(null);
 _emptyTask = source.Task;
 }

 public override Task DoStuffAsync()
 {
 return _emptyTask;
 }
}
</code></pre>

Then I remember the "issue" with static constructors and performance, and after research a little (that is how I get here), I decide to do a small benchmark:

<pre><code>Stopwatch sw = new Stopwatch();
List&lt;Int64&gt; test1list = new List&lt;Int64&gt;(), test2list = new List&lt;Int64&gt;();

for (int j = 0; j &lt; 100; j++)
{
 sw.Start();
 for (int i = 0; i &lt; 1000000; i++)
 {
 Test1 t = new Test1();
 if (!t.DoStuffAsync().IsCompleted)
 throw new Exception();
 }
 sw.Stop();
 test1list.Add(sw.ElapsedMilliseconds);

 sw.Reset();
 sw.Start();
 for (int i = 0; i &lt; 1000000; i++)
 {
 Test2 t = new Test2();
 if (!t.DoStuffAsync().IsCompleted)
 throw new Exception();
 }
 sw.Stop();
 test2list.Add(sw.ElapsedMilliseconds);

 sw.Reset();
 GC.Collect();
}

Console.WriteLine("Test 1: " + test1list.Average().ToString() + "ms.");
Console.WriteLine("Test 2: " + test2list.Average().ToString() + "ms.");
</code></pre>

And the results are quite clear:

<pre><code> Test 1: 53.07 ms. 
 Test 2: 5.03 ms. 
 end
</code></pre>

So despite of having a static constructor, the benefit outweighs the issue. So always measure.

Recently read in a article on dotnetpearls.com <a href="http://dotnetperls.com/static-constructor" rel="noreferrer">here</a> saying that static ctors take a substantial amount of perfomance hit. 

Could not fathom why?

Static constructors cause a performance overhead?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

最近在dotnetpearls.com 的一篇文章中读到，静态ctor会对性能造成很大的影响。不能理解为什么？

问静态构造函数会导致性能开销吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问静态构造函数会导致性能开销吗？EN