有效使用ASP.NET RegisterStartupScript方法

Question

当我在后台代码中加载数据时，我经常发现我想基于我的数据运行多个javascript函数。 使用StringBuilder编译所有函数调用并一次发出RegisterStartupScript效率更高，或者如果每次需要时都发出RegisterStartupScript，性能是否相同？

Answer 1

我认为使用StringBuilder的实现会更有效率，因为您无需创建任何控件，仅在完成后才注册脚本。 您可能希望继续使用StringBuilder方法的另一个原因是，已注册脚本的顺序是否重要。

从MSDN：

当页面加载完成时，但在引发页面的OnLoad事件之前，将执行RegisterStartupScript方法添加的脚本块。 不能保证脚本块按其注册顺序输出。 如果脚本块的顺序很重要，请使用StringBuilder对象将脚本收集到单个字符串中，然后将它们全部注册在单个客户端脚本块中。

Answer 2

如果您担心使用字符串连接构建脚本会导致内存重新分配效率低下，那么不必担心。 您注册的脚本存储在ListDictionary（System.Collections.Specialized命名空间）中，因此，如果未使用适当数量的内存实例化StringBuilder，则为此列表分配的内存实际上比使用StringBuilder更快。 不必在一处建立所有脚本，这还有一个好处。

ListDictionary的工作方式就像一个单链列表，因此虽然我不确定，但我无法想象为什么没有任何脚本会按注册顺序添加到页面的原因。

Answer 3

通常，在您知道自己有性能问题之前，不尝试解决性能问题会更有效率。 最好先解决性能最差的问题。

另一方面，您正在做的事情称为“预优化”。 这不是一个好主意。

其他人将添加Knuth报价。

---

为什么预优化是一件坏事？

我们大多数人并没有获得使事情变得最好的报酬。 我们得到完成工作的报酬。

有时，这项工作需要我们提高代码的性能。 那时，最好先找出性能需要改进的地方，而不是提前决定我们要看的地方。

“预优化”提前决定应提高性能。 很有可能这不能解决下一个更严重的问题。 实际上，如果不进行衡量，您可能会使情况变得更糟，甚至一无所知。

更糟糕的是，您花费在解决错误问题上的时间本可以花在解决正确的问题上，而这正是花费公司的钱。 即使您每页调用100个脚本， RegisterStartupScript可能不会使您的公司付出任何代价。 特别是，它的成本不会比脚本本身的低效实现或不良设计所引起的费用高。

我不知道您的情况是否正确，但就我而言，在大学两年后我患上了这种疾病。 幸运的是，两年后我没钱了，不得不去现实世界工作。 那是教会我理论与实践之间的差异的一件事。

第二件事，最近的事情是花几天的时间优化内存泄漏，我被告知在那里。 事实证明，没有内存泄漏，但情况更糟。 我一直在解决错误的问题。

---

克努斯语录

“我们应该忘记效率低下的问题，大约有97％的时间是这样：过早的优化是万恶之源。”

来自http://en.wikipedia.org/wiki/Optimization_(computer_science）