4

事情是这样的：

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

我想要的方式：

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

... B 在通用级别上是否比 A 性能更好？

将代码重构为从样式 A 到样式 B 的功能奇偶性是一项艰巨的任务，因此我无法对我的断言进行任何有意义的实际测试，但与作用域函数样式相比，Monolithic God 对象反模式是否是一个已知的性能怪物? 为了易读性、代码安全和关注点分离，我会为 B 辩护......但我想将所有内容一直保存在内存中，通过查找链等进行爬行，这将使其成为访问任何内容的固有性能密集型练习，或者至少使垃圾收集成为一项非常困难的任务。

4

1 回答 1

2

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

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

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

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

如果你使用 Try.. Catch 块，它们就不能被有效地编译。但是，如果您将 Try...Catch 块中的代码包装到函数中，那确实会有所帮助。

因此，对于提高性能来说，最重要的任务就是将大部分静态的东西写成一个函数。并且不要多次更改定义的对象。

将代码包装在自执行函数中可能无济于事，因为它仍保留在内存中。但是附加的函数定义可能会以不同的方式编译。不过，因为它只是一个包装函数，所以应该几乎没有区别。

于 2013-02-19T16:04:51.973 回答