我很难理解为什么我的"并发"实现http://www.codeproject.com/Tips/447938/High-performance-Csharp-byte-array-to-hex-string-t函数只有大约20%的性能增益。
为了方便起见，这里是该网站的代码：
static readonly int[] toHexTable = new int[] {
3145776, 3211312, 3276848, 3342384, 3407920, 3473456, 3538992, 3604528, 3670064, 3735600,
4259888, 4325424, 4390960, 4456496, 4522032, 4587568, 3145777, 3211313, 3276849, 3342385,
3407921, 3473457, 3538993, 3604529, 3670065, 3735601, 4259889, 4325425, 4390961, 4456497,
4522033, 4587569, 3145778, 3211314, 3276850, 3342386, 3407922, 3473458, 3538994, 3604530,
3670066, 3735602, 4259890, 4325426, 4390962, 4456498, 4522034, 4587570, 3145779, 3211315,
3276851, 3342387, 3407923, 3473459, 3538995, 3604531, 3670067, 3735603, 4259891, 4325427,
4390963, 4456499, 4522035, 4587571, 3145780, 3211316, 3276852, 3342388, 3407924, 3473460,
3538996, 3604532, 3670068, 3735604, 4259892, 4325428, 4390964, 4456500, 4522036, 4587572,
3145781, 3211317, 3276853, 3342389, 3407925, 3473461, 3538997, 3604533, 3670069, 3735605,
4259893, 4325429, 4390965, 4456501, 4522037, 4587573, 3145782, 3211318, 3276854, 3342390,
3407926, 3473462, 3538998, 3604534, 3670070, 3735606, 4259894, 4325430, 4390966, 4456502,
4522038, 4587574, 3145783, 3211319, 3276855, 3342391, 3407927, 3473463, 3538999, 3604535,
3670071, 3735607, 4259895, 4325431, 4390967, 4456503, 4522039, 4587575, 3145784, 3211320,
3276856, 3342392, 3407928, 3473464, 3539000, 3604536, 3670072, 3735608, 4259896, 4325432,
4390968, 4456504, 4522040, 4587576, 3145785, 3211321, 3276857, 3342393, 3407929, 3473465,
3539001, 3604537, 3670073, 3735609, 4259897, 4325433, 4390969, 4456505, 4522041, 4587577,
3145793, 3211329, 3276865, 3342401, 3407937, 3473473, 3539009, 3604545, 3670081, 3735617,
4259905, 4325441, 4390977, 4456513, 4522049, 4587585, 3145794, 3211330, 3276866, 3342402,
3407938, 3473474, 3539010, 3604546, 3670082, 3735618, 4259906, 4325442, 4390978, 4456514,
4522050, 4587586, 3145795, 3211331, 3276867, 3342403, 3407939, 3473475, 3539011, 3604547,
3670083, 3735619, 4259907, 4325443, 4390979, 4456515, 4522051, 4587587, 3145796, 3211332,
3276868, 3342404, 3407940, 3473476, 3539012, 3604548, 3670084, 3735620, 4259908, 4325444,
4390980, 4456516, 4522052, 4587588, 3145797, 3211333, 3276869, 3342405, 3407941, 3473477,
3539013, 3604549, 3670085, 3735621, 4259909, 4325445, 4390981, 4456517, 4522053, 4587589,
3145798, 3211334, 3276870, 3342406, 3407942, 3473478, 3539014, 3604550, 3670086, 3735622,
4259910, 4325446, 4390982, 4456518, 4522054, 4587590
};
public static unsafe string ToHex1(byte[] source)
{
fixed (int* hexRef = toHexTable)
fixed (byte* sourceRef = source)
{
byte* s = sourceRef;
int resultLen = (source.Length << 1);
var result = new string(' ', resultLen);
fixed (char* resultRef = result)
{
int* pair = (int*)resultRef;
while (*pair != 0)
*pair++ = hexRef[*s++];
return result;
}
}
}
以下是我的"改进"：
public static unsafe string ToHex1p(byte[] source)
{
var chunks = Environment.ProcessorCount;
var n = (int)Math.Ceiling(source.Length / (double)chunks);
int resultLen = (source.Length << 1);
var result = new string(' ', resultLen);
Parallel.For(0, chunks, k =>
{
var l = Math.Min(source.Length, (k + 1) * n);
fixed (char* resultRef = result) fixed (byte* sourceRef = source)
{
int from = n * k;
int to = (int)resultRef + (l << 2);
int* pair = (int*)resultRef + from;
byte* s = sourceRef + from;
while ((int)pair != to)
*pair++ = toHexTable[*s++];
}
});
return result;
}
编辑1这就是我对功能计时的方式：
var n = 0xff;
var s = new System.Diagnostics.Stopwatch();
var d = Enumerable.Repeat<byte>(0xce, (int)Math.Pow(2, 23)).ToArray();
s.Start();
for (var i = 0; i < n; ++i)
{
Binary.ToHex1(d);
}
Console.WriteLine(s.ElapsedMilliseconds / (double)n);
s.Restart();
for (var i = 0; i < n; ++i)
{
Binary.ToHex1p(d);
}
Console.WriteLine(s.ElapsedMilliseconds / (double)n);
在反复讨论了您的示例之后，我得出结论，您看到的时间差异很大程度上是由于GC开销造成的，两种场景中的初始化开销都足够高，即使从测试中删除了GC开销，性能差异也相对不重要。
当我切换测试顺序时，平行的测试比非平行的测试结束得更快。这是测试不公平的第一个迹象。：)
当我更改测试，以便在每次测试后调用GC.Collect()，以确保GC在随后的测试中保持安静时，并行版本始终领先。但只是勉强如此；每个线程的启动时间在所有情况下都超过了每个并行测试的总持续时间的一半。
作为测试的一部分，我修改了代码，以便它跟踪For()版本的每个线程中花费的实际时间。在这里，我发现在这段代码中花费的时间大约是我基于非并行版本所期望的时间(即，相当接近时间除以线程数)。
(当然，也可以使用探查器获取这些信息)。
以下是我使用GC.Collect()运行的测试的输出。对于并行测试，这也显示了每个线程的开始时间(相对于整个测试开始时间)和持续时间。
首先运行非并行版本，其次运行并行版本：
单线程版本：00:00:00.6726813
并行版本：00:001:00.6270247
nbsp；线程#0：开始时间：00:00:00.33343985，持续时间：00:00:0.2925963
nbsp；线程#1：开始时间：00:00:00.335640，持续时间：00:00:0.2805527单线程版本：00:00:00.7027335
并行版本：00:00:0.5610246
nbsp；线程#0：开始时间：00:00:00.305695，持续时间：00:00:0.0.2304486
nbsp；线程#1：开始时间：00:00:00.305857，持续时间：00:00:0.2300950单线程版本：00:00:00.6609645
并行版本：00:001:00.6143675
nbsp；线程#0：开始时间：00:00:00.3391491，持续时间：00:00:0.2750529
nbsp；线程#1：开始时间：00:00:00.3391560，持续时间：00:00:0.2705631单线程版本：00:00:00.6655265
并行版本：00:000:00.6246624
nbsp；线程#0：开始时间：00:00:00.2227595，持续时间：00:00:0.22924611
nbsp；线程#1：开始时间：00:00:00.227831，持续时间：00:00:0.3018066单线程版本：00:00:00.6815009
并行版本：00:001:00.5707794
nbsp；线程#0：开始时间：00:00:00.227074，持续时间：00:00:0.2400668
nbsp；线程#1：开始时间：00:00:00.227330，持续时间：00:00:0.24478351
首先运行并行版本，其次运行非并行版本：
并行版本：00:00:00.5807343
nbsp 线程#0：开始时间：00:00:00.3397320，持续时间：00:00:0.24009767
nbsp；线程#1：开始时间：00:00:00.3398103，持续时间：00:00:0.2408334
单线程版本：00:00:00.6974992并行版本：00:00:00.5801044
nbsp；线程#0：开始时间：00:00:00.305571，持续时间：00:00:0.2495409
nbsp；线程#1：开始时间：00:00:00.335746，持续时间：00:00:0.249293
单线程版本：00:00:00.744293并行版本：00:00:00.5845514
nbsp；线程#0：开始时间：00:00:00.33454512，持续时间：00:00:0.2352147
nbsp；线程#1：开始时间：00:00:00.33454756，持续时间：00:00:0.2389522
单线程版本：00:00:00.6542540并行版本：00:00:00.5909125
nbsp；线程#0：开始时间：00:00:00.3356177，持续时间：00:00:0.2500365
nbsp；线程#1：开始时间：00:00:00.3356250，持续时间：00:00:0.02552392
单线程版本：00:00:00.7609139并行版本：00:00:00.5777678
nbsp；线程#0：开始时间：00:00:00.3440084，持续时间：00:00:0.2337504
nbsp；线程#1：开始时间：00:00:00.34400323，持续时间：00:00:0.0.2329294
单线程版本：00:00:00.6596119
经验教训：
- 性能测试很棘手，尤其是在托管环境中。像垃圾收集和即时编译这样的事情使得很难将苹果与苹果进行比较
- 与程序可能花费时间做的任何其他事情(如准备和调用线程)相比，将字节转换为字符的实际计算成本完全无关紧要。这种特殊的算法似乎不值得并行化；尽管你确实在速度上得到了持续的提高，但由于实际计算的所有开销，这是非常微不足道的
最后一点：这类测试中的另一个错误来源是英特尔的超线程。或者更确切地说，如果您在使用启用Hyperthread的CPU计数的同时进行测试，您会得到误导性的结果。例如，我在基于英特尔i5的笔记本电脑上测试了这一点，该笔记本电脑报告有4核。但是，在非并行实现中，运行四个线程不会接近4倍的加速，而运行两个线程会接近2倍的加速(对于正确的问题)。这就是为什么尽管我的计算机报告有4个CPU，但我只测试了2个线程。
在这里，这个测试中还有太多其他误导性的开销，我认为超线程没有太大的区别。但这是需要注意的。
我在第一个答案的评论中读到(顺便说一句，这比问题和评论的内容更丰富)，这些测试的执行时间最多在25ms左右。
关于这一点，有很多话要说，但第一句话是"多么浪费好的程序员时间！">
这是一个明显的过度优化的情况。当我第一次浏览代码时，我想"为什么有人想并行处理这个问题？"你正在进行非常快速的逐位操作。首先没有足够的性能惩罚来证明并行性是合理的。
现在，谈谈你的测试差异。TPL是一个复杂的库，并行性比单线程复杂一个数量级。因此，在运行测试时，有许多因素会起作用，其中一些(但并非全部)在各种评论中都提到了。每个因素都以一种不可预测的方式影响结果，你可以把每个因素看作是增加了一点变化。最终，您的测试结果没有足够的能力来区分两者，这是过度优化的又一个迹象。
作为程序员，我们需要记住，我们的时间是极其昂贵的，尤其是与计算机时间相比。在编程时，实现真正的、增值的性能提升的机会很少，通常集中在非常昂贵的处理或需要从远程服务器请求的情况下，等等。有时确实需要，但这不是其中之一。