可以使用分析器，但是为什么不停止该程序呢? [英] One could use a profiler, but why not just halt the program?

问题描述

如果某个东西使单线程程序花费的时间比原来要长10倍，则可以在其上运行探查器.您也可以使用暂停"按钮将其暂停，然后您会确切地看到它在做什么.

If something is making a single-thread program take, say, 10 times as long as it should, you could run a profiler on it. You could also just halt it with a "pause" button, and you'll see exactly what it's doing.

即使它只比原本慢了10％，但如果将其暂停多次，不久之后，您就会看到它反复做不必要的事情.通常，问题出在真正不需要的堆栈中间某处的函数调用上.这不能解决问题，但可以找到.

Even if it's only 10% slower than it should be, if you halt it more times, before long you'll see it repeatedly doing the unnecessary thing. Usually the problem is a function call somewhere in the middle of the stack that isn't really needed. This doesn't measure the problem, but it sure does find it.

异议大多假定您仅抽取1个样本.如果您是认真的人，请使用10.平均导致那部分样本的任何一行代码都会浪费在堆栈上，例如40％.瓶颈(在单线程代码中)无法隐藏.

The objections mostly assume that you only take 1 sample. If you're serious, take 10. Any line of code causing some percentage of wastage, like 40%, will appear on the stack on that fraction of samples, on average. Bottlenecks (in single-thread code) can't hide from it.

为了表明我的意思，许多异议的形式是样本不足，所以您看到的可能完全是虚假的"-关于机会的含糊想法.但是，如果30％的时间内有效的任何可识别的描述(不仅在例程中或例程处于活动状态)有效，那么在任何给定样本上看到它的可能性为30％ .

To show what I mean, many objections are of the form "there aren't enough samples, so what you see could be entirely spurious" - vague ideas about chance. But if something of any recognizable description, not just being in a routine or the routine being active, is in effect for 30% of the time, then the probability of seeing it on any given sample is 30%.

然后假设仅抽取10个样本.在二项式分布之后，将在10个样本中看到问题的次数以及看到它0次是.028.看到它1次的可能性是.121.对于2倍，该概率为.233，对于3倍，该概率为.267，此后下降.由于看到它的次数少于两次的概率为0.028 + .121 = .139，这意味着看到它的次数两次或更多次的概率为1-.139 = .861.一般规则是，如果看到可以在两个或多个样本上修复的东西，则值得修复.

Then suppose only 10 samples are taken. The number of times the problem will be seen in 10 samples follows a binomial distribution, and the probability of seeing it 0 times is .028. The probability of seeing it 1 time is .121. For 2 times, the probability is .233, and for 3 times it is .267, after which it falls off. Since the probability of seeing it less than two times is .028 + .121 = .139, that means the probability of seeing it two or more times is 1 - .139 = .861. The general rule is if you see something you could fix on two or more samples, it is worth fixing.

在这种情况下，在10个样本中看到它的机会为86％.如果您在14％的受访者中看不到它，请多做一些样本，直到您看到为止. (如果样本数量增加到20，则两次或多次看到它的机会会增加到99％以上.)因此，尚未对其进行精确测量，但已对其进行精确发现，了解这一点很重要可能很容易是探查器无法实际找到的东西，例如涉及数据状态的东西，而不是程序计数器.

In this case, the chance of seeing it in 10 samples is 86%. If you're in the 14% who don't see it, just take more samples until you do. (If the number of samples is increased to 20, the chance of seeing it two or more times increases to more than 99%.) So it hasn't been precisely measured, but it has been precisely found, and it's important to understand that it could easily be something that a profiler could not actually find, such as something involving the state of the data, not the program counter.

推荐答案

在Java服务器上，执行2-3个快速 Ctrl - Breaks 一直是一个绝妙的窍门连续获取所有正在运行的线程的2-3个线程转储.只需查看所有线程的位置"，就可以非常快速地找出性能问题所在的位置.

On Java servers it's always been a neat trick to do 2-3 quick Ctrl-Breakss in a row and get 2-3 threaddumps of all running threads. Simply looking at where all the threads "are" may extremely quickly pinpoint where your performance problems are.

这种技术可以在2分钟内揭示出比我所知道的任何其他技术更多的性能问题.

This technique can reveal more performance problems in 2 minutes than any other technique I know of.

这篇关于可以使用分析器，但是为什么不停止该程序呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！