javascript扩展预建原型性能答案

【问题标题】：javascript extending prebuilt prototypes performancejavascript扩展预建原型性能
【发布时间】：2018-04-03 11:05:54
【问题描述】：

许多人认为，扩展预构建的原型（例如 String、Array 或 Object）是不好的做法。

但是，其他人说它也有可怕的性能损失 - 这是有道理的，因为我认为某种哈希表中的缓存方法现在无效（因为您可以更改该方法）。

我想知道的是，如果你们所有的原型在执行开始时都对原生类型进行了一次扩展，并且在使用原型链中包含该原型的任何对象之前，这还会有性能问题吗？

我问的原因是因为我正在开发一个编译为 javascript 的系统。我不关心 javascript 中的不良做法，但我绝对关心性能！

【问题讨论】：

【解决方案1】：

就像@Jonas 所说，性能很可能不会成为问题。

扩展原型实际上是很多 pollyfills 的工作原理。

但是你要问的问题是，你打算使用任何第三方库，还是打算把它变成一个库供其他人使用。如果是这样，请避免覆盖内置原型，因为它可能会破坏很多东西..

如果这只是在内部使用，在你的控制下我看不出有任何问题，只要你当然不对内置的做一些愚蠢的事情。

为了额外的安全，我还会考虑在你的所有方法前面加上一些不太可能成为规范一部分的东西……例如..String.prototype.myCaptializer，我非常怀疑这会成为规范的一部分……

【讨论】：

您怎么知道性能不会成为问题？我可以很容易地看到一个具有原生内置方法的系统，例如 indexOf。但是如果你编辑数组类型的原型，这个系统可能会回退到总是检查数组原型中是否存在 indexOf 方法。
方法会有奇怪的数字名称，例如“123_method_toString”或短字符串，例如“3”
How do you know performance won't be an issue? 因为我说过 -> avoid the overriding built in prototype's 覆盖 indexOf 如果性能是关键，当然不是一个好主意。
123_method_toString 这不是一个有效的方法名称，所以你不能在它们上使用dot notation。 my123_method_toString & my3 或某种前缀会更好。
对不起，它是 method_name_{随机数}。无论如何，你能解释一下为什么在构建方法中覆盖内置原型会影响性能吗？您对此说法有确凿的证据吗？

【解决方案2】：

我不认为性能是真正的问题。真正的问题是：

  Object.prototype.toString = () => "whoops";

  console.log({} + ", whats going on here?!");

【讨论】：

对，但对于我的用途，我正在编译为 javascript，所以我不介意完全出乎意料的行为。我只关心我的 Linq 表达式树和编译后的 javascript 之间的契约是否得到满足。