什么是“(程序)”?在 Chrome 调试器的分析器中?

发布于 2024-09-25 12:49:11 字数 32 浏览 1 评论 0原文

Chrome调试器的功能栏中的“(程序)”是什么?

What is “(program)” in the function column of the Chrome debugger?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

黑色毁心梦 2024-10-02 12:49:11

(program) 是 Chrome 本身,是调用所有其他代码的树的根...它在那里是因为从本机代码到 JavaScript 的跳转、资源加载等必须从某个地方开始 /em> :)

您可以在 中查看树视图示例Chrome 开发者工具文档

(program) is Chrome itself, the root of the tree calling all other code...it's there because the jump from native code to JavaScript, resource loading, etc. has to start somewhere :)

You can see examples of the treeview in the Chrome developer tool docs.

小瓶盖 2024-10-02 12:49:11

我相信(程序)是本机代码,而不是树的根。

请参阅此帖子:

https://bugs.webkit.org/show_bug.cgi?id=88446

,更像是系统调用而不是 main()。

显然它包括空闲时间。另外,(程序)的一些分析可以从 chrome://profiler/ 获得。

I believe (program) is native code, not the root of the tree.

See this thread:

https://bugs.webkit.org/show_bug.cgi?id=88446

So, more like system calls than like main().

Apparently it includes idle time. Also, some profiling of (program) is available from chrome://profiler/

2024-10-02 12:49:11

正如@Nick 所说,它必须从某个地方开始。

看起来 CPU Profiler 部分就像许多其他分析器一样,它们基于与 gprof 相同的概念。

例如,self 几乎是一个无用的数字,除非您可以编辑某些代码中存在类似于对大量数字进行冒泡排序的操作。可能性极小。

总计应该包括被调用者,所以这更有用。然而,除非在阻塞时间和运行时间期间都进行采样,否则除了完全受 CPU 限制的程序外,它仍然毫无用处。

它通过函数而不是代码行为您提供这些统计信息。这意味着(如果你可以依赖Total百分比)一个函数的成本是那么高,从某种意义上说,如果你能以某种方式让它花费零时间,比如通过存根它,那么这个百分比就是多少你会节省时间。

因此,如果您想专注于一个成本高昂的功能,您需要在其中寻找可以优化的内容。为此,您需要知道如何在函数中的代码行之间细分时间。如果您有基于一行代码的成本,它将直接带您到这些行。

我不知道您是否能够获得更好的分析器,例如在行级别报告的挂钟堆栈采样器,例如 缩放。这是我是如何做到的

As @Nick says, it has to start somewhere.

It looks like the CPU Profiler part is like so many other profilers that are based on the same concepts as gprof.

For example, self is nearly a useless number unless there is something like a bubble-sort of a big array of numbers in some code that you can edit. Highly unlikely.

Total should include callees, so that's more useful. However, unless samples are taken during blocked time as well as during running time, it is still pretty useless except for totally cpu-bound programs.

It gives you these stats by function, rather than by line of code. That means (if you could rely on Total percent) that a function costs that much, in the sense that if you could somehow make it take zero time, such as by stubbing it, that percent is how much time you would save.

So if you want to focus on a costly function, you need to hunt inside it for what could be optimized. In order to do that, you need to know how the time is subdivided among the lines of code in the function. If you had cost on a line of code basis, it would take you directly to those lines.

I don't know if you will be able to get a better profiler, like a wall-clock stack sampler reporting at the line level, such as Zoom. Here's how I do it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文