javascript - Javascript 中的 Monolithic God 对象是否存在性能问题？

Question

是这样的:

我最近加入了一个 webapp 项目，作为标准，它维护一个全局可用的(即它本身是 window 的属性)对象，它包含作为属性或递归子 -属性、运行应用程序所需的所有函数和变量——包括所有小部件的状态指示器、初始化别名、通用 DOM 操作方法——一切。我会尝试用简化的伪代码来说明，但这违背了我的关注点，即这个东西是独眼巨人。基本上没有任何东西是封装的:所有单个粒度组件都可以从任何地方读取或修改。

我喜欢的方式:

在我最近的工作中，我一直是高级或唯一的 Javascript 开发人员，所以我能够以一种使用函数的风格编写代码，这些函数通常会立即调用/自动执行，用于确定谨慎代码块的范围并将粒度基元保持为这些范围内的变量。使用这种模式，默认情况下一切都锁定在其执行范围内，偶尔会在需要公开 API 的情况下返回一些经过明智选择的 getter/setter 函数。

…在一般层面上，B 是否比 A 表现更好？

将代码重构为从样式 A 到样式 B 的功能对等是一项艰巨的任务，因此我无法对我的断言进行任何有意义的实际测试，但是与作用域功能风格？为了易读性、代码安全和关注点分离，我会为 B 争论......但我想一直将所有内容保存在内存中，爬过查找链等将使它成为访问任何内容的固有性能密集型练习，或者至少使垃圾收集成为一项非常困难的任务。

Answer 1

需要考虑的事情很少，内存密集型程序不一定越慢。

此外，即使您使用自执行函数，并且只公开了几个函数，函数的其余部分仍保留在内存中，因为公开的函数可能需要它。由于闭包导致的内存泄漏，现在是网络上的热门话题。

现在，同样假设 v8 的工作方式，javascript 代码被编译为 C++，然后进行汇编。现在，经常使用的函数变成了热门代码，并且函数的相同缓存版本被一遍又一遍地使用。对象也有类似的情况。

但是，如果您稍后编辑对象，则会重新编译该对象并且会影响性​​能。

如果您使用 Try.. Catch block ，则无法有效地编译它们。但是，如果您将 Try...Catch block 中的代码包装到函数中，那确实有帮助。

因此，真正提高性能速度的最重要任务是将大部分静态内容编写为函数。并且不要多次更改定义的对象。

将您的代码包装在一个自执行函数中可能不会有太大帮助，因为它仍然保存在内存中。但是额外的函数定义可能会以不同的方式编译。尽管如此，因为它只是一个包装函数，所以应该几乎没有任何区别。