了解 Firebug 分析器输出
我一直在尝试使用 Firebug 的分析器来更好地理解我们所看到的一些 JavaScript 性能问题的根源，但我对输出有点困惑。
当我分析某些代码时，分析器会报告分析（464.323 毫秒，26,412 次调用）。 我怀疑 464.323 毫秒是这 26,412 个调用的执行时间的总和。
然而，当我深入查看详细结果时，我看到各个结果的平均执行时间大于 464.323 毫秒，例如，平均时间最长的结果报告以下详细信息：
Calls: **1**
Percent: **0%**
Own Time: **0.006 ms**
Time: **783.506 ms**
Avg: **783.506 ms**
Min: **783.506 ms**
Max: **783.506 ms**
另一个结果报告：
Calls: **4**
Percent: **0.01%**
Own Time: **0.032 ms**
Time: **785.279 ms**
Avg: **196.32 ms**
Min: **0.012 ms**
Max: **783.741 ms**
在这些之间两个结果的时间结果总和远大于 464.323。
那么，这些不同的数字意味着什么？ 我应该相信哪些？
I've been trying to use Firebug's profiler to better understand the source of some JavaScript performance issues we are seeing, but I'm a little confused by the output.
When I profile some code the profiler reports Profile (464.323 ms, 26,412 calls). I suspect that the 464.323 ms is the sum of the execution time for those 26,412 calls.
However, when I drill down into the detailed results I see individual results with an average execution time greater than 464.323 ms, e.g. the result with the highest average time reports the following details:
Calls: **1**
Percent: **0%**
Own Time: **0.006 ms**
Time: **783.506 ms**
Avg: **783.506 ms**
Min: **783.506 ms**
Max: **783.506 ms**
Another result reports:
Calls: **4**
Percent: **0.01%**
Own Time: **0.032 ms**
Time: **785.279 ms**
Avg: **196.32 ms**
Min: **0.012 ms**
Max: **783.741 ms**
Between these two results the sum of the Time results is a lot more than 464.323.
So, what do these various numbers mean? Which ones should I trust?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
每列都有一个说明，说明在 Firebug 中将鼠标悬停在其上方时的含义。 我假设您可以自己阅读每一列的工作原理。 但是，您肯定遇到过一些需要解释的奇怪行为。
自己的时间是函数在其内部执行代码所花费的时间。 如果该函数不调用其他函数，则自己的时间应与时间相同。 但是，如果存在嵌套函数调用，则 time 还会计算执行它们所花费的时间。 因此，时间几乎总是大于自己的时间，并且在大多数情况下加起来会超过探查器报告的总时间。
但是，单个函数的时间不应大于探查器记录的 JavaScript 调用的总时间。 这个问题绝对是一个错误，我可以理解为什么当 Firebug 给你提供如此矛盾的输出时你很难相信它。 我相信我已经找到了这个错误发生的原因：AJAX。
AJAX 调用似乎导致对嵌套函数调用进行计数的列报告不正确的信息。 他们最终会计算 JavaScript 执行时间和对服务器的请求。
您可以通过执行以下操作来重现此探查器错误：
http://juicystudio.com/experiments/ajax/index.php)
在此示例中，关于时间与自己的时间，每个函数的自己的时间加起来就是探查器的总时间，但是< em>time 列包含 AJAX 调用与服务器通信所花费的时间。 这意味着，如果您只想查看 JavaScript 执行的速度，那么时间列是不正确的。
它变得最糟糕：因为时间，平均时间，分钟和最大都计算嵌套函数调用，它们是如果您使用 AJAX，则一切都不正确。 最重要的是，任何最终使用 AJAX（在嵌套函数调用中）的函数也将错误地报告其时间。 这意味着很多函数可能会报告不正确的信息！ 因此，在 Firebug 修复问题之前，暂时不要相信任何这些列。 （他们可能希望这种行为是这样的，尽管保持这种方式充其量会令人困惑。）
如果您没有使用 AJAX，那么另一个问题就会出现； 如果您是或不是，请告诉我们。
Each column has a description of what it means if you set your mouse to hover over it in Firebug. I'll assume you can read up on how each column works on your own then. However, you have definitely come across some odd behavior which needs to be explained.
The own time is the amount of time the function spent executing code inside of itself. If the function calls no other functions, then own time should be the same as time. However, if there are nested function calls, then time also counts the time spent executing them. Therefore, time will almost always be larger than own time, and will in most cases add up to more than the total time reported by the profiler.
However, no single function's time should be larger than the total time the profiler logged for JavaScript calls. This problem is definitely a bug, and I can see why you have trouble trusting Firebug when it gives you such a paradoxical output. I believe I've tracked down the reason this bug occurs: AJAX.
It appears that AJAX calls are causing columns that count nested function calls to report incorrect information. They end up counting both the time of JavaScript execution and the request to the server.
You can reproduce this profiler bug by doing the following:
http://juicystudio.com/experiments/ajax/index.php)
In this example, with regards to time vs. own time, the own time of each function adds up to the profiler's total time but the time column incorporates the amount of time the AJAX call took to talk to the server. This means that the time column is incorrect if you're looking for just the speed of JavaScript execution.
It gets worst: since time, average time, min and max all count nested function calls, they're all incorrect if you're using AJAX. On top of that, any function that eventually uses AJAX (in a nested function call) will also report their time incorrectly. This means that a whole lot of functions may be reporting incorrect information! So don't trust any of those columns for now until Firebug fixes the issue. (It's possible they intended the behavior to be this way, though it is confusing at best to leave it this way.)
If you're not using AJAX, then another issue is at play; let us know if you are or not.
如果我理解正确的话，它是这样的：
在第一行，你会看到自己的时间是“只有 0.006 毫秒”。 这意味着尽管在该函数中花费的时间为 783.506ms，但大部分时间都花费在从该函数调用的函数内。
当我使用 Firebug 优化代码时，我尝试减少被调用最多的函数的“自己的时间”。 （显然还要检查是否有任何不必要的函数调用要完全删除）
If I understand things correctly it goes something like this:
On the first line you'll see that the Own time is "only 0.006ms". That means that even though time spent in that function was 783.506ms most of it was spent inside functions called from that function.
When I use Firebug to optimize code I try to reduce the "own time" of functions that are called the most. (obviously checking also for any unnecessary function calls to remove altogether)
来自 Firebug 教程 - 日志记录、分析和命令行（第二部分）：
（里面的例子很好）
From Firebug Tutorial - Logging, Profiling and CommandLine (Part II):
(the examples there are good)
据我了解，这就是它的工作原理...总探查器时间是“自己的时间”列的总和。 但是，您可能会注意到某些单个时间值可能大于分析器总时间。 这些加班时间都花在了 JavaScript 之外，例如。 在插件调用中。 如果您的 JS 函数进行插件调用，并等待插件函数返回 JS，那么这些等待时间将不会被总探查器时间报告，但将包含在“时间”列中。
From what I understand this is how it works... total profiler time is the sum of the 'Own Time' column. However, you may notice that some single Time values may be greater than the total profiler time. Those overtimes were spent outside of JavaScript, eg. in a plugin call. If your JS function makes a plugin call for eg., and waits for the plugin function to return to JS, then those waiting times will NOT be reported by the total profiler time, but will be included in the Time column.