我有一個庫，它在describeType（）（一個返回包含類或實例的所有規格的XML對象）的頂部提供反射API。由於這個庫在其他幾個庫和框架中使用，我真的希望它儘可能快。性能重構（和測試）
我面臨的問題是，我不確定重構此庫的代碼的最佳方法，並使測試和比較結果成爲可能。我可以很容易地將定時器添加到代碼中，記錄輸出並比較結果，但手動執行此操作似乎有很多工作要做。
因此，這給我帶來了以下幾個問題：
您可以使用FlashBuilder（不是免費）的分析器來查看可以改進的地方。
可以使用TDSI例如（仍處於發展和更優化會）
在字節碼級優化（不接觸源）如果你想看看是怎麼回事引擎蓋下和了解更多編譯代碼，看看tamarin的源代碼（Adobe Flash在flash播放器中的使用）並學習abc bytecode
或者編寫多個函數並測量它們的性能，一步一步做小的重構，看看有什麼收穫，可以使用gskinner library進行測量（不要使用調試播放器，因爲某些功能比較慢）。
閱讀關於as3 optimisation的一些論文。有好的人喜歡Joa Ebert,Grant Skinner。
但是，如果優化後的增益較小，則更願意保持代碼的可讀性。
你想要一個profiler。你的編譯器應該有一個，例如gprof自帶GCC - 有a tutorial here。
測量和找到是不同的問題。
您可以通過查找並修復需要花費最多時間的代碼來快速完成代碼，這不是測量，而是取樣 - 時間越長，找到它所需的樣本越少。
什麼衡量是好的是看到多少時間實際上保存。
採樣不丟棄信息很重要。單獨的程序計數器（as in gprof）是不夠的。您至少需要整個調用堆棧進行採樣。查看行級信息非常重要，因爲在函數中總結了丟棄信息。在隨機掛鐘時間而不是隨機CPU時間進行採樣很重要（如gprof和其他分析器）。隨機CPU時間的採樣對於花費在不必要的I/O或系統功能上的時間是盲目的。
一個好的分析器是RotateRight/Zoom。我使用this technique。