有效使用ASP.NET RegisterStartupScript方法

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

我认为使用

StringBuilder

实现会更高效，因为您不创建任何控件，只在完成后注册脚本。您可能希望继续使用

StringBuilder

方法的另一个原因是注册脚本的顺序是否重要

从

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

---

通常情况下，在发现性能问题之前，不尝试解决性能问题会更有效率。最好先解决最糟糕的性能问题

另一方面，你所做的被称为“预优化”。这被认为不是个好主意

其他人将添加Knuth引号

---

为什么预先优化是件坏事？ 我们中的大多数人并不是为了把事情做到最好而得到报酬的。我们得到报酬是为了完成一项工作

有时，这项工作需要我们改进代码的性能。在那个时候，最好找出性能需要改进的地方，而不是提前决定我们想去哪里

“预优化”提前决定了性能应该得到改进。很可能这并不能解决下一个更糟糕的问题。事实上，如果不进行测量，你可能会让事情变得更糟，而且永远不会知道

更糟糕的是，你花在解决错误问题上的时间可能会花在解决正确的问题上——这会让你的公司付出代价。很可能，

RegisterStartupScript

不会让您的公司花费任何金钱，即使您以每页100个脚本的价格调用它。特别是，它的成本不会像脚本本身的低效实现或糟糕设计那样高

我不知道你的情况是否属实，但在我的情况下，我在大学两年后患上了这种疾病。幸运的是，两年后我没钱了，不得不去现实世界工作。这就是让我认识到学校理论和实践现实之间的区别的原因之一

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

---

克努特语录 “我们应该忘记小效率，比如说97%的时间：过早优化是万恶之源。”

---

从

如果您担心使用字符串连接构建脚本时会出现低效的内存重新分配，那么不要担心。您注册的脚本存储在ListDictionary（System.Collections.Specialized命名空间）中，因此如果StringBuilder没有使用适当的内存量进行实例化，则此列表的内存分配实际上可能比使用StringBuilder更快。还有一个好处是不必在一个地方构建所有脚本

---

ListDictionary的工作原理类似于一个单链表，因此虽然我不确定，但我无法想象脚本为什么不按注册顺序添加到页面中。

我认为粗体语句是关键。谢谢我看不出有什么问题。我只是问一种方法是否比另一种更有效。我认为这比埋在沙堆里，不去寻找更好的方法更好。