如何测试实现运行速度更快的方法

Question

虽然问题check if input is type of string已经结束，但我的脑海中浮现出一个微观优化问题：下面两个解决方案中的哪一个会表现得更好？

Reed Copsey提供了solution using Char.IsLetter：

string myString = "RandomStringOfLetters";
bool allLetters = myString.All( c => Char.IsLetter(c) );

从solution using regex改编Mark Byers：

string s = "RandomStringOfLetters";
bool allLetters = Regex.IsMatch(s, "^[a-z]+$", RegexOptions.IgnoreCase);

不想只问里德或马克的问题我以为我会写一个快速测试来确定哪个表现更好。问题是我没有做过很多代码优化（我倾向于将代码可读性放在首位）。

除了在每个运行之前和之后采用时间戳之外，还有哪些其他（更好的？）选项可以确定哪个解决方案运行得更快？

修改

我修改了Martin's answer以使用Console.WriteLine(...)并将其作为控制台应用程序运行。不确定LinqPad如何运行应用程序，但结果大致相同：

41
178

Answer 1

您需要执行此操作，使用Stopwatch来衡量运行时。此外，在分析时要记住以下几个非常重要的事项：

1. 总是运行您的测试超过一次。第一次运行时，JIT会产生开销，时间可能会产生误导。运行多次并取平均值是一种很好的方法（例如，我经常会进行100,000次这样的测试。）
2. 始终在Visual Studio托管过程之外使用完整版本构建运行测试。 （默认情况下，您可以使用Ctrl + F5。）Visual Studio主机会显着影响计时。

Answer 2

你应该看看System.Diagnostics.Stopwatch！

  

http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx

你应该在一个循环中多次运行这个东西，以减少计时错误和其他无法控制的因素。

希望有所帮助。

Answer 3

我只是把它放在LINQPad中，作为我如何做的例子（因此调用Dump（） - 如果你没有使用这个，请用Console.WriteLine（...）替换方便的工具）。

看起来LINQ方式的速度略快超过四倍：

System.Diagnostics.Stopwatch stopwatch = new Stopwatch();

stopwatch.Start();
for (int i = 0; i < 100000; i++)
{
 string myString = "RandomStringOfLetters";
 bool allLetters = myString.All( c => Char.IsLetter(c) );
}
stopwatch.Stop();
stopwatch.ElapsedMilliseconds.Dump();

stopwatch.Reset();

stopwatch.Start();
for (int i = 0; i < 100000; i++)
{
 string s = "RandomStringOfLetters";
 bool allLetters = Regex.IsMatch(s, "^[a-z]+$", RegexOptions.IgnoreCase);
}
stopwatch.Stop();
stopwatch.ElapsedMilliseconds.Dump();

输出：

47 
196

Answer 4

可以使用System.Diagnostics.Stopwatch类。

无论您测试什么代码，运行测试一次以删除JIT成本，然后再次运行它以获得最终时间。由于PC上的其他因素，大多数单独的计时计数可能无法代表 - 因此运行多次迭代，然后从中计算平均运行时间。

Answer 5

使用System.Diagnostics.Stopwatch类。

启动StopWatch并运行数千次迭代，停止并检查已经过去的总毫秒数

Answer 6

确定哪个更快的步骤： -

1. 获取一组计算机，应该做几百台，AMD / Intel /其他，32位/ 64位，......

2. 在每个.NET框架（依次）上安装您关心的每个.NET框架

3. 尝试每种组合的优化选项进行编译（反过来）

4. 使用StopWatch测试每个

的大量运行

5. 监控每个内存的利用率，因为这可能会对应用程序的其余部分产生更大的影响。以增加内存消耗和更多垃圾收集活动为代价来节省几个周期往往是一个糟糕的“优化”。

可能会让你知道哪个在实践中更快，至少对于当前版本的编译器而言。对每个新版本的编译器重复。