对 yourkit .NET 探查器有何意见？
有人使用 yourkit 制作的 .NET 分析器吗？我正在寻找一款优秀的 .NET 分析器，并偶然发现了 yourkit。因为我要购买单人许可证，所以我需要花费 79 欧元，恕我直言，这还不错。我还喜欢的是：或多或少易于使用且友好的 GUI。
但我在分析 .NET 应用程序方面不是很有经验，所以我想知道 yourkit .NET 分析器是否能完成工作。不过，Yourkit 在 Java 世界中似乎相当有名。
有什么意见吗？
Is anybody using the .NET profiler made by yourkit? I am looking for a good .NET profiler and stumbled upon the yourkit one. As I would purchase a single person license, it would cost 79 EUR for me, which is pretty ok imho. What I also like: the more or less easy to use and friendly GUI.
But I am not very experienced in profiling .NET applications, so I wonder if yourkit .NET profiler gets the job done. Yourkit seems to be pretty well known in the Java world, though.
Any opinions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
观点？是的。当您决定购买或不购买哪个分析器时，尝试一下。
添加：@Max：分步说明：IDE 有一个“暂停”按钮。在 IDE 下运行您的应用程序，当它主观上很慢时，即在您等待它时，请点击“暂停”按钮。然后获取调用堆栈的快照。
为了拍摄调用堆栈的快照，我所做的就是显示它（这是调试窗口之一）。在 IDE 选项中，您可以找到在堆栈视图中显示内容的选项。我关闭了显示函数参数的选项，因为这会使行太长。我对发生调用的行号和被调用函数的名称感兴趣。然后，在调用堆栈视图中，您可以执行“全选”，然后执行“复制”，然后将其粘贴到记事本中。我知道这有点笨拙，但我过去常常用手写下来。
我用这种方法取了一些样本。然后我会查看它们是否出现在多个样本上的线条，因为这些线条是耗时的。有些只是必要的，例如“call main”，但有些则不是。 这些都是金块。如果我没有找到任何东西，我会继续取样，最多大约 20 个。如果到那时我仍然没有找到任何东西（非常不寻常），那么程序就很好了优化得很好。 （一个关键点是，每次执行此操作时，程序都会变得更快，并且在这个过程中，剩余的性能问题会变得相对更大并且更容易发现。即，不仅程序会以一定的比率 R 变得更快，而且剩余的性能问题也会变得更快。问题以相同的比例按百分比变得更大。）*
在此过程中我做的另一件事是问自己程序在做什么以及为什么在该示例中。 “为什么”非常重要，因为这是您判断一条生产线是否确实必要或是否可以用成本较低的东西替代的方式。如果我不确定它为什么在那里，我会稍微单步执行，也许查看数据，或者让它返回几个级别（shift-F11），直到我明白它在做什么。这就是全部内容了。
如果现有的分析器实际执行堆栈采样、保留样本、根据包含样本的百分比对行进行排名，然后让您详细研究各个样本，则可以帮助完成此过程。也许他们将来会这样做，但现在还没有。他们专注于效率和衡量等问题。
*假设你的代码用 90% 的时间做 X，用 9% 的时间做 Y，两者都没有必要。采取少量样本，您将看到 X，但可能看不到 Y。如果修复 X，您将获得 10 倍的加速。再次进行采样（您可能必须在程序周围包裹一个外循环，以便可以采样）。现在您可以确定地看到 Y，因为现在它需要 9% x 10x = 90%。修复它可以让你再获得 10 倍的加速，整体加速达到 100 倍。
Opinion? Yeah. While you're deciding which profiler to buy or not, give this a try.
ADDED: @Max: Step-by-step instructions: The IDE has a "pause" button. Run your app under the IDE, and while it is being subjectively slow, i.e. while you are waiting for it, hit the "pause" button. Then get a snapshot of the call stack.
To snapshot the call stack, what I do is display it (that's one of the debug windows). In the IDE options you can find options for what to display in the stack view. I turn off the option to display the function arguments, because that makes the lines too long. I'm interested in the line number where the call takes place and the name of the function being called. Then, in the call stack view, you can do a "Select All" and then a "Copy", and then paste it into Notepad. It's a little clumsy, I know, but I used to write them down by hand.
I take a few samples this way. Then I look at them for lines that appear on more than one sample, because those are the time-takers. Some are simply necessary, like "call main", but some are not. Those are the gold nuggets. If I don't find any, I keep taking samples, up to about 20. If I still don't find any (very unusual) by that time the program is pretty well optimized. (A key point is that every time you do this the program gets faster, and in the process the remaining performance problems get relatively bigger & easier to find. I.e. not only does the program get faster by a certain ratio R, but the remaining problems get bigger, percentage-wise, by that same ratio.)*
Another thing I do in this process is ask myself what the program is doing and why in that sample. The "why" is very important, because that is how you tell if a line is actually necessary or could be replaced with something less costly. If I'm not sure why it is there, I single-step it a little, maybe look at the data, or maybe let it return up a few levels (shift-F11) until I understand what it's doing. That's about all there is to it.
Existing profilers could help with this process if they actually perform stack sampling, retain the samples, rank lines by what percent of samples contain them, and then let you study individual samples in detail. Maybe they will at some time, but they don't now. They are hung up on issues like efficiency and measurement.
*Suppose your code spends 90% of its time doing X, and 9% of its time doing Y, both not really necessary. Take a small number of samples, and you will see X, but probably not Y. If you fix X you get a 10x speedup. Do the sampling again (you may have to wrap an outer loop around the program so you can take samples). Now you see Y with certainty because now it takes 9% x 10x = 90%. Fixing it gives you another 10x, for overall 100x speedup.
免责声明：我的建议基于以下假设：您认真对待性能分析，并且希望了解调优工作的准确改进百分比。
根据我使用 ANTS 和 DotTrace 等性能分析器的经验，我认为它们很有用，但都会在某一时刻失败。
通用性能分析器的问题是它们增加了太多开销并使结果不准确。但他们在发现大量操作方面做得很好。当您使用分析器并发现某个操作占用了总处理时间的 40% 时，它实际上占用了 40% 吗？也许不是。但它可能确实需要很多时间来运行。
因此，要回答你的问题，你的套件是“优秀”还是“令人满意”并不重要，除非它太糟糕以至于你听到了关于它的可怕故事。因为它将让您全面了解应用程序中的性能瓶颈。让您了解在哪里插入您自己的时间记录指令，以了解应用程序的实际性能概况。
附言。我还建议您阅读性能分析，这将为您提供对概念的整体理解并有助于理解其他人的建议。
Disclaimer: my suggestion is based on the assumption that you are serious about performance profiling, and would like to find out the accurate % improvement of your tuning effort.
Based on my experience with performance profilers like ANTS and DotTrace, I think they are useful while all fail at one point or another.
The problem with general purpose performance profilers is they add too much overhead and render the result inaccurate. But they do however, a good job at finding heavy operations. When you use a profiler and find an operation taking 40% of the total process time, does it actually take 40%? Maybe not. But it probably does take a lot of time to run.
So to answer your question, it doesn't matter whether yourkit is "excellent" or "satisfactory", unless it sucks so bad that you hear horrible stories about it. Because it is going to give you a big picture of performance bottlenecks in your app. Giving you an idea where to insert your own time logging instructions to find out the actual performance profile of your application.
PS. I would also suggest you take a read about performance profiling, which would give you an overall understanding of the concept and help understand other people's suggestions.