如何测试应用程序的启动时间或性能
有一个名为 PassMark AppTimer 的免费工具。但我认为它不太适合我的需求。
Windows提供了一个名为xperf的工具，有没有办法使用它来测试/基准应用程序启动时间？
There is a free tool called PassMark AppTimer. But I think it's not quite fit for my needs.
Windows provides a tool called xperf, is there a way to use it to test/benchmark application startup time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我正在帮助开发一个应用程序，并且它在启动（或任何其他阶段）时变得太慢，我就是这么做的。
普遍的看法是，测量各种例程的性能对于发现性能问题是必要的。
我走了另一条路——我找到了最大的问题（因为它们的缓慢暴露了它们），然后我可以粗略地估计它们花费了多少时间，如果我愿意的话。 的示例。
以下是其工作原理 例如，我发现：1）从资源中获取和转换字符串，这些字符串位于资源中，以便它们可以国际化，但实际上并不需要国际化，或者2）创建和删除（以及序列化）深层数据结构在设置 UI 控件的过程中没有真正的原因。
发现的东西几乎从来都不是你猜测的那样，所以猜测是错误的。只需看看该过程告诉您什么即可。
有趣的是，问题几乎从来都不是分析器可以轻易告诉您的事情。问题几乎总是一些看起来无辜的函数或方法调用，位于调用堆栈中间的某个地方，只会引起您的注意，因为 1) 它显示了很多，2) 通过查看什么它在做什么以及为什么，你可以看到它可以不做。摆脱它可以节省与它在堆栈上一样多的时间。
If I'm helping to develop an app, and it gets too slow on startup (or any other phase), I just do this.
Common wisdom is that measuring performance of various routines is necessary for finding performance problems.
I go the other way - I locate the biggest problems (because their very slowness exposes them), and then I can roughly estimate how much time they take, if I care to. Here's an example of how it works.
The kinds of things I have found are, for example 1) fetching and converting strings from resources, which were in resources so that they could be internationalized, but did not really need to be internationalized, or 2) creating and deleting (along with serializing) deep data structures for no real reason in the process of setting up UI controls.
The things found are almost never what you might guess, so it is a mistake to guess. Just see what the process tells you.
The interesting thing about this is that the problem is almost never the kind of thing that profilers could easily tell you. The problem is nearly always some innocent-looking function or method call, somewhere in the middle of the call stack, that only gets your attention because 1) it shows up a lot, and 2) by looking at what it is doing and why, you can see that it can be done without. Getting rid of it saves as much time as it was on the stack.