测量函数、类和进程速度的最佳方法
衡量函数和类速度的最佳方法是什么？对于每个功能都有各种解决方案，我想知道如何测量运行速度并使用最佳解决方案优化我的共享类。
另外，如何衡量 SQL 速度，例如存储过程、选择、视图等之间的差异？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
衡量函数和类速度的最佳方法是什么？对于每个功能都有各种解决方案，我想知道如何测量运行速度并使用最佳解决方案优化我的共享类。
另外，如何衡量 SQL 速度，例如存储过程、选择、视图等之间的差异？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
你有两个选择。
使用
System.Diagnostics.Stopwatch用于特定方法。这是 .NET 中的高分辨率计时器，您可以将其用于代码的特定部分。
如果需要测量整个应用程序的性能，请使用探查器。
您可以使用 Visual Studio Ultra 版本的内置探查器，或 EQATEC。
You have two options.
Use
System.Diagnostics.Stopwatchfor specific methods.This is a high resolution timer in .NET which you can use for specific parts of your code.
Use a profiler if you need to measure performance for your entire application.
You can use the build in profiler of the Ultra edition of Visual Studio, or a tool like EQATEC.
您最好使用分析器。测量挂钟执行时间（例如由 Stopwatch 类完成）的问题在于，它受到许多远远超出您控制范围的因素的影响。仅举几个此类因素，包括网络和其他 I/O 延迟以及影响应用程序和线程的相对优先级的操作系统调度程序决策。如果您在虚拟化环境中运行，这也会对毫秒范围的挂钟时间测量产生相对较大的影响。探查器并不完美，但它可以让您更好地了解执行代码实际花费了多少时间。
除此之外，一个好的分析器通常还可以为您提供其他有用的指标，例如代码在执行过程中使用了多少内存。
You're best off using a profiler. The problem with measuring wallclock execution time (such as done by the
Stopwatchclass) is that it is influenced by many factors far out of your control. To mention just a few such factors, there's network and other I/O latency, and operating system scheduler decisions which influence the relative priority of applications and threads. If you are running inside a virtualized environment, that can also have a comparatively large effect on millisecond-range wallclock time measurements. The profiler won't be perfect, but it will give you a better idea of how much time is actually spent executing your code.Besides that, a good profiler can often give you other useful metrics as well, like how much memory your code uses during execution.
最好不要混淆测量和优化的目标。它们是不同的任务。测量虽然有助于量化修复某些问题的结果，但无法告诉您要修复什么。
在测量方面，如果我想演示某事物的速度有多快，我需要一个受控的环境和一个好的秒表。然而，为了优化的目的，粗略的测量（比如运行 1000 次）和使用简单的计时器就足够了。
关于优化，我并不关心速度。
我担心不必要的活动。
不需要高速运行代码来找到它。
当任何程序运行时，它都会跟踪调用树。
优化包括删除尽可能多的叶子（指令）和尽可能多的水果（I/O）。
一个好方法是修剪整个树枝。
为了找到这些，我认为挂钟时间堆栈采样是最好的方法。这不一定是一个有效的过程，并且相当少量的样本与大量样本一样好（或更好）。
有必要重复执行此操作，因为任何给定的程序在第一次编写时都不只包含一次加速机会。它包含几个。
这是一个示例。
It's best not to confuse the goals of measuring and optimizing. They are different tasks. Measuring, while good for quantifying the results of fixing something, is poor at telling you what to fix.
On the subject of measuring, if I want to make a presentation of how fast something is, I want a controlled environment and a good stopwatch. However, for the purpose of optimizing, crude measurements (like running something 1000 times) and using a simple timer, are more than good enough.
On the subject of optimizing, I am not concerned with speed.
I am concerned with needless activity.
It is not necessary to run the code at high speed to find it.
When any program runs, it traces out a call tree.
Optimizing consists of removing as many leaves (instructions) and as much fruit (I/O) as possible.
A good way to do this is to prune whole branches.
To find those, I think wall-clock time stack sampling is the best way. It is not necessary for this to be an efficient process, and a rather small number of samples works just as well (or better) than a large number of samples.
It is necessary to do it repeatedly, because any given program, as first written, doesn't contain just one opportunity for speedup. It contains several.
Here's an example.