如何测量 Firefox 附加内存使用情况

发布于 2025-01-03 04:04:31 字数 120 浏览 0 评论 0原文

我正在使用 XUL 开发一个 Firefox 插件，我想测量和分析我的扩展内存使用情况。
我该怎么做？并检查哪个函数占用的内存最多，以及我的扩展向 Firefox 添加了多少内存使用量？

原文

分享到QQ

分享到微博

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

发布评论

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

旧瑾黎汐 2025-01-10 04:04:31

您无法衡量单个功能的影响，Firefox 中的内存管理在此级别不起作用 - 它适用于隔间。如果您的扩展程序有自己的窗口，那么您将能够在 about:memory?verbose 下看到该窗口的分区（点击“最小化内存使用”，否则您可能会看到那里的对象是垃圾）无论如何收集）。如果您的扩展程序的代码在浏览器窗口的上下文中运行，那么您通常会运气不佳 - 您将无法将其与在那里运行的其他脚本区分开来。 XPCOM 组件和 JavaScript 模块也是如此 - 所有这些都被加载到“[系统主体]”隔间中。

然而，你可以做些什么来让你的脚本与一个大的隔间分开：使用沙箱，沙箱总是有自己的隔间。例如，在浏览器窗口中，您可以执行以下操作：

Components.utils.import("resource://gre/modules/Services.jsm");
var mySandbox = Components.utils.Sandbox(window,
                  {sandboxName: "myExtension/browserScript.js"});
mySandbox.window = window; // Expose window variable to scripts in the sandbox
Services.scriptloader.loadSubScript("chrome://myextension/content/browserScript.js",
                                    mySandbox);
mySandbox.init();  // Call function init() of the script in the sandbox

因此，名为 myExtension/browserScript.js 的隔间将显示在 about:memory?verbose 下，并且您将能够看到该脚本（以及它创建的对象等）到底占用了多少内存。要记住的事情：

沙箱中的脚本无法从“外部”访问变量。您必须显式地将这些变量设置为沙箱的属性（就像我在示例中对 window 变量所做的那样）。
隔间并不便宜，在隔间之间传递物体也不便宜。因此，为每个功能创建一个隔间将是一个坏主意，因为涉及到管理费用。

文档：沙箱、Services.jsm

更新：从 Firefox 13 开始，情况发生了变化。例如，此扩展将向您显示当前中的所有对象记忆。仍然远非舒适，而且了解整个情况也很重要 - 但它为您提供了低于隔间级别的粒度。

You cannot measure the impact of a single function, the memory management in Firefox doesn't work at this level - it works with compartments. If your extension has its own window then you will be able to see the compartment of this window under about:memory?verbose (click "Minimize memory usage", otherwise you might see objects there that will be garbage collected anyway). If your extension's code runs in the context of the browser window then you are usually out of luck - you will not be able to distinguish it from the other scripts running there. It's the same with XPCOM components and JavaScript modules - all of them get loaded into the "[System Principal]" compartment.

What you can do to get your scripts separated from a large compartment however: use sandboxes, a sandbox always gets its own compartment. For example, in a browser window you would do something like this:

Components.utils.import("resource://gre/modules/Services.jsm");
var mySandbox = Components.utils.Sandbox(window,
                  {sandboxName: "myExtension/browserScript.js"});
mySandbox.window = window; // Expose window variable to scripts in the sandbox
Services.scriptloader.loadSubScript("chrome://myextension/content/browserScript.js",
                                    mySandbox);
mySandbox.init();  // Call function init() of the script in the sandbox

As a result, a compartment called myExtension/browserScript.js will be displayed under about:memory?verbose and you will be able to see how much memory this script (along with objects it creates etc.) takes exactly. Things to keep in mind:

The script in the sandbox won't have access to the variables from "outside". You have to explicitly set these variables as properties of the sandbox (like I've done with the window variable in the example).
Compartments aren't cheap, and passing objects between compartments isn't cheap either. So creating one compartment for each function would be a bad idea because of the overheads involved.

Documentation: Sandbox, Services.jsm

Update: As of Firefox 13 things changed. There is this extension for example that will show you all the objects currently in memory. Still far from being comfortable, also getting the whole picture is non-trivial - but it gives you granularity on a level below compartments.

回复收藏 0 原文

~没有更多了~