我和一位同事正在查看 VS2012 中的 Visual Studio Profiling 报告,他们问我,“为什么要使用百分比来表示方法中的持续时间或调用方法所花费的时间?”
我的解释是该工具提供了一些表示哪些方法/调用需要很长时间或方法的哪些部分需要很长时间。现在这可以是抽象(百分比)或绝对值(时间(毫秒)),但任何一个都足以将您指向应用程序中的问题区域。
我们对此并不特别相信,所以我想我会问互联网。
我和一位同事正在查看 VS2012 中的 Visual Studio Profiling 报告,他们问我,“为什么要使用百分比来表示方法中的持续时间或调用方法所花费的时间?”
我的解释是该工具提供了一些表示哪些方法/调用需要很长时间或方法的哪些部分需要很长时间。现在这可以是抽象(百分比)或绝对值(时间(毫秒)),但任何一个都足以将您指向应用程序中的问题区域。
我们对此并不特别相信,所以我想我会问互联网。
这是来自 Visual Studio Profiler 团队的 Andre Hamilton。这些值是百分比而不是 ms 的原因是因为您看到的是基于 Sample Profiling 而不是基于 Instrumentation 的分析的报告。
Sample Profiling 基本上操作系统会定期进行堆栈遍历。您在分析报告中看到的结果代表操作系统执行堆栈遍历时特定函数在堆栈上的时间比例
Instrumentation Profiling 我们基本上修改二进制文件(静态或动态)并截取函数的开始和结束。然后,我们在启动和退出函数时获取时间戳。这将为您提供有关函数执行的精确信息,但并非没有成本。因为在每个函数进入和退出时都会获取信息,因此生成的分析报告可能非常庞大(只需几秒钟的程序执行就拥有超过 1GB 的数据并不是未知的)。此外,如果在已签名的二进制文件上使用静态检测,您将需要让它们辞职。这可能会使开发过程复杂化。动态检测在此处有所帮助,但这并不能为您节省数据开销。
仅供参考,Visual Studio 带有用于静态检测的 vsinstr(可在 \Team Tools\Performance Tools 中找到)。
目标是什么?
只是获得时间测量,你可以把它放在一个幻灯片上?或者...
找出如何让整个事情花费更少的时间?(除了在更快的芯片上运行它。)
如果目标是 (2),那么要做的事情是在软件中找到 a) 占挂钟时间很大百分比的活动,并且 b) 不是绝对必要的。原因是如果您可以摆脱占用 X(如 50%)时间的活动,那么您获得的加速因子高达 1/(1-X) 或两倍。
我在这里小心使用“活动”这个词,因为它是一个非常笼统的概念。如果您只认为自己在寻找“慢程序”,那么您将错过很大的加速机会,如果您真的关心性能,那是您无法承受的。
关键是加速机会就像岩石一样。它们有多种形式,并且有多种尺寸。如果你不删除它们中的每一个,你将与那些你没有得到的人一起生活。例如,如果有 3 个,当移除它们时,它们可以节省 50%、25% 和 12.5%,那么如果你同时做这三个,你会得到 8 倍的加速。非常好。但是,如果你错过了其中的一个,你就无法接近那个。
剖析师应该是探石者,但如果他们错过了一个,你怎么知道?如果分析器的输出看起来令人印象深刻,但似乎并没有表明您可以实际修复多少,这是否意味着没有? 没有。 更多关于这一切。
实际上,除了百分比之外,一些分析器确实给出了绝对时间。
真正的问题是这些时间有多有用,考虑到您可以根据当前机器负载和当前机器的规格等因素获得不同的时间。另外,请记住,当您在分析器中运行代码时,它的运行速度会比未分析的运行慢,因此即使分析的运行也不能准确反映真实的运行时间。
由于这些原因,有些人可能认为绝对时间无关紧要。然后,如果您假设时间之间的变化是乘以某个数字,那么百分比就是要查看的数量。然后,该百分比将保留绝对时间之间的比率,因此如果某件事花费了两倍的时间,它将有两倍的百分比。
当然,百分比并不完美,因为不能保证更改会是乘法的(例如,开销会是加法的)。
以毫秒为单位的时间会因许多因素而异——你的开发机器可能有四个处理器和 32gb 的 RAM——但用户机器可能只有单核和 1gb 的 RAM。
一致的(主要是1)是“花费时间最长的位” - 因此百分比可以帮助您识别代码中最慢的部分,这些部分是您可以通过优化获得最多时间的部分。
1尽管编译器如何基于处理器优化代码。
百分比很好。但是需要有以毫秒为单位的时间。如果您必须比较执行相同任务的两个版本的软件,一个比另一个花费更长的时间。百分比比在每个函数中花费的绝对时间更难比较。为什么不让我们选择查看绝对时间的百分比呢?
我很惊讶这还没有被提出。