在.NET性能分析性能、NET

2023-09-03 04:15:33 作者:独钓一江月

我写了一个类,它使用秒表来分析方法和为/的foreach 循环。随着的foreach 循环它测试对一个标准的循环的Parallel.For Parallel.ForEach 的实施。

I wrote a class which uses Stopwatch to profile methods and for/foreach loops. With for and foreach loops it tests a standard loop against a Parallel.For or Parallel.ForEach implementation.

您会写性能测试,像这样:

You would write performance tests like so:

方法:

PerformanceResult result = Profiler.Execute(() => { FooBar(); });

For循环:

SerialParallelPerformanceResult result = Profiler.For(0, 100, x => { FooBar(x); });

ForEach循环:

SerialParallelPerformanceResult result = Profiler.ForEach(list, item => { FooBar(item); });

每当我进行的测试,(一个.Execute 。对于。的ForEach )我将它们放在一个循环,所以我可以看到随着时间的性能变化。

Whenever I run the tests (one of .Execute, .For or .ForEach) I put them in a loop so I can see how the performance changes over time.

性能例子是:

方法执行1 = 200毫秒 方法执行2 = 12ms的 方法执行3 = 0毫秒

Method execution 1 = 200ms Method execution 2 = 12ms Method execution 3 = 0ms

有关执行1 = 300毫秒(串口),100毫秒(并行) 对于执行2 = 20毫秒(串口),75ms(并行) 对于执行3 = 2毫秒(串口),50毫秒(并行)

For execution 1 = 300ms (Serial), 100ms (Parallel) For execution 2 = 20ms (Serial), 75ms (Parallel) For execution 3 = 2ms (Serial), 50ms (Parallel)

的ForEach执行1 = 350毫秒(串口),300毫秒(并行) 的ForEach执行2 = 24ms(串口),89ms(并行) 的ForEach执行3 = 1毫秒(串口),21ms(并行)

ForEach execution 1 = 350ms (Serial), 300ms (Parallel) ForEach execution 2 = 24ms (Serial), 89ms (Parallel) ForEach execution 3 = 1ms (Serial), 21ms (Parallel)

我的问题是:

为什么性能随时间的变化,什么是.NET做后台,方便吗?

Why does performance change over time, what is .NET doing in the background to facilitate this?

如何/为什么是一个串行操作不是并行的速度更快?我已经确定,我让操作复杂,看到其中的差别正确......在大多数情况下连续操作似乎更快!?

How/why is a serial operation faster than a parallel one? I have made sure that I make the operations complex to see the difference properly...in most cases serial operations seem faster!?

注意:对于并行处理我测试了8核的机器上

NOTE: For parallel processing I am testing on an 8 core machine.

推荐答案

在一些探索性能分析,我发现,用秒表是不准确的方法来衡量一个特定任务的执行

After some more exploration into performance profiling, I have discovered that using a Stopwatch is not an accurate way to measure the performance of a particular task

(感谢斧头和罗兰您对此有何评论!)的

原因秒表是不准确的:

测量计算在经过时间以毫秒为单位,而不是CPU时间。 测量可以通过背景噪音的影响和线程密集的过程。 在测量不考虑JIT编译和开销。

话虽这么说,用秒表对休闲的探索表现确定。考虑到这一点,我已经提高了我的分析算法一些。

That being said, using a stopwatch is OK for casual exploration of performance. With that in mind, I have improved my profiling algorithm somewhat.

在哪里之前,它只是执行传递给它的前pression,它现在拥有的设施遍历EX pression几次,建筑的平均执行时间。第一次运行可以省略,因为这是在JIT开始发​​挥作用,可能会发生一些重大开销。可以理解的是,这将永远是那么复杂使用专业的分析工具一样的展鹏的蚂蚁分析器,但它是简单的任务OK!

Where before it simply executed the expression that was passed to it, it now has the facility to iterate over the expression several times, building an average execution time. The first run can be omitted since this is where JIT kicks in, and some major overhead may occur. Understandably, this will never be as sophisticated as using a professional profiling tool like Redgate's ANTS profiler, but it's OK for simpler tasks!