PostSharp 对速度没有影响
我偶然发现 PostSharp 具有难以置信的良好性能。为了评估速度，我编写了一个小程序，它将执行一个函数指定的次数，如果启用 PostSharp，它将生成并删除几百个字符串，就在内存中（非固定组合，因此它们不会自动生成）实习）。该循环的执行时间很长（几毫秒）。
现在，我无法测量几百万次运行的差异，并且大约 400 亿次迭代的疯狂运行相当于与执行相同数量调用的非 PostSharp 版本相比仅几纳秒的差异。对我来说，这是不可能的。我的测试一定有问题。我的同事对代码进行了同行评审，所以我相当有信心代码达到了我的预期目的。
那么，使用字符串生成（这是预期应用程序中的预期用途）作为基准测试的缓慢运行模拟是否有问题？
或者，其他人是否执行过（或知道）PostSharp 的运行时性能分析？
谢谢。
I have stumbled on an impossibly good performance behaviour with PostSharp. To evaluate the speed I wrote a little program, that would execute one function a specified number of times, and if PostSharp is enable it would generate and delete a few hundred strings, just in memory (non fixed composition, so they are not auto-interned). The loop executes in a non-trivial (a few milliseconds) amount of time.
Now, I am unable to measure the difference on a few million runs, and a crazy run of ~40 billion iterations amounted to a difference of just a few nanoseconds vs non-PostSharp version doing the same number of calls. To me, this is impossible. There must be something wrong with my test. I had the code peer-reviewed by my co-workers, so I am fairly confident the code does what I intend it to.
So, is there something wrong with using string generation (which is the expected use in the intended applications) as the slow-running simulation for the benchmarks?
Alternatively, has someone else performed (or know of) a PostSharp's runtime performance analysis?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 3 GHz 处理器上，仅 400 亿个时钟周期就需要 13 秒 - 我真诚地怀疑单次迭代只需要一个时钟周期。你的测试肯定有问题。
有些东西可能会被优化——也许它发现你一遍又一遍地做同样的事情，并决定根本不做（除了第一次）。您需要确保在进行性能分析时随机化数据。
On a 3 GHz processor, 40 billion clock cycles alone will take 13 seconds - and I sincerely doubt that a single iteration is taking just one clock cycle. Something's definitely wrong with your test.
Something's likely getting optimized away - maybe it sees that you're doing the same thing over and over again and is deciding not to do it at all (except the first time). You need to make sure you're randomizing your data when you do perf analysis.
我已经做了性能测试。它们发布于 PostSharp Blog
如果不使用反射、访问方法参数、访问方法实例等功能，某些方面可以具有与手写代码相同的性能。由于 PostSharp 发出 MSIL 指令，因此生成的代码可以由 JIT 编译器内联。
正如其他答案中所提醒的，请确保 (1) PostSharp 确实被调用（在生成的程序集上使用 Reflector）并且 (2) 您正确使用了秒表。如果您比较单个测试的平均时间，PostSharp 和手写代码之间的差异只有几纳秒是正常的（假设您不使用昂贵的功能）。
I have done performance tests. They were published in PostSharp Blog
Some aspects can have the same performance as hand written code if they don't use features such as: reflection, access to method parameters, access to method instance. Since PostSharp emits MSIL instructions, the generated code can be inlined by the JIT compiler.
As reminded in other answers, be sure that (1) PostSharp is indeed invoked (use Reflector on the resulting assembly) and (2) you're using the Stopwatch properly. If you're comparing the average time of a single test, it's normal that the difference between PostSharp and hand-written code is just a few nanoseconds (in the hypothesis that you don't use expensive features).
您可以更改您的测试，以便在下一次迭代中使用生成的字符串（写入控制台的字符串长度）或类似的东西吗？
也许编译器会以这样的方式优化您的程序：postsharp 函数根本不执行，或者异步调用或在另一个 cpu 上执行，因为没有理由与其他迭代同步。如果您将其链接得更紧密，这可能会迫使编译器同步操作。
Can you change your test, such that the generated strings are used in the next iteration (string length written to the console) or something like that?
Maybe the compiler optimizes your program in such a way that either the postsharp-function is not executed at all or that it is called asynchronously or executed on another cpu, because there is no reason to sync with the other iterations. If you link it more tightly, this may force then the compiler, to synchronize the actions.