更多资源密集型：在所有域上运行的Tampermonkey脚本（用于视频控制） - 或者只有1K域，每个域都有自己的@include条目？

Question

我有一个简单的问题 - 如果答案是（或应该）显而易见，我会事先道歉......这个问题可能会背叛我基本的（即基本上不存在的）代码流利性。

但我在Tampermonkey中写了一个.js用户脚本，让我可以更精确地控制Safari中的视频播放。我已将它设置为在所有域上运行：

// @include http://*
// @include https://*  

虽然到目前为止这对我来说当然有用，但我知道脚本在我上网的80％上不必要地运行，我不会涉及与视频元素的任何交互...所以我经历并编制了详尽的列表约1,000个特定域，其中脚本运行是有意义的，例如：

// @include     *://*.facebook.com/*
// @include     *://*.vimeo.com/*
// @include     *://*.youtube.com/*

但实际上在我的[以前非常娇小的！]用户中输入了1000行之后，我明白了 - 据我所知 - 我实际上可能会大大增加运行此脚本所需的系统资源量通过强制它现在运行一长串域名来查看它是否匹配...并且可能只是让它默认运行可能会减少资源密集度？

哈，与此同时，我也可以想象它到处运行它显然更多地浪费资源......但是因为我不知道我怎么去测试它（我当然没有坚实的在这里对基础理论的充分把握） - >我想我会把它交给专家，并在这里向你们寻求建议！

谢谢您的帮助！！ :-)

Answer 1

部分答案，因为它对评论来说太大了，因为我现在没有兴趣设置和运行一些新实验。 （如果有人用更新的，可验证的数字发布答案，那么它就会得到我的支持。）

这里有一个草图，说明当你有Tampermonkey，Violentmonkey等并安装了用户脚本时会发生什么：

1. 您访问的每个页面都会根据每个活动用户的@include，@match和@exclude指令进行检查。更智能的引擎将首先检查@exclude并在找到匹配时停止。 有些引擎比其他引擎更好地进行此检查，理想情况下，站点匹配信息将保留在内存中以获得最大速度。
2. 您访问的所有页面上的每个<frame>或iframe都会根据每个活动用户的@include，@match和@exclude指令进行检查，除非该脚本设置了@noframes。
3. 如果脚本与页面（或框架）匹配，则Tampermonkey（etc）必须： （A）获取脚本代码和任何数据 - 通常来自磁盘（慢）。 （B）然后创建一定级别的沙箱 - 取决于引擎，浏览器和@grant模式。 （C）将脚本注入上述沙箱 - 几乎总是由匿名函数包装 - 然后运行它。
4. 然后，用户脚本将使用资源，具体取决于其代码。

一般来说：

1. @match比@include表现更好（比前几年检查过）。如果您要使用1000行，请使用@match而不是include。
2. 除非你有理由不使用@noframes。
3. 理想情况下，步骤1和2可以从内存中完成（需要查看各种引擎当前的操作），并且可以在注入一个用户脚本的同时处理大量@includes。 （有人想尝试收集一些数字吗？）
4. 如果需要从磁盘中提取用户脚本或其数据（@require文件，@resource文件，GM_setValue数据），那么这相当大的时间滞后。 （但仍然比从互联网上获取东西更快。）

最后，必须将每次编辑用户脚本文件所需的时间和可能的压力与必须与脚本的侵入性进行比较。

如果是我，并且脚本只将页面延迟了大约300毫秒，我只是捏住我的鼻子并使用：

// @match    *://*/*
// @noframes

但是，如果脚本更具侵入性，更慢或更耗费资源，则可以使用混合方法... 保持网站列表在GM_setValue数据和/或@resourced文件中完全运行。

这样你就可以使用例如菜单命令动态编辑列表;或通过Tampermonkey脚本数据编辑器;甚至可以通过您为此目的创建的按钮。然而，所有这些都超出了这个问题的范围。