有效使用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）