關於代碼運行效率問題的一個總結和一點疑問

來源:互聯網
上載者:User
  首先要承認,這個隨筆的名字起得有點兒彆扭。
  自從自己開發GEA52以來,就一直思考有關程式運行效率的問題。按照自己以往的思路,程式運行得慢了,可能的情形有很多,效能瓶頸可能出現在Web伺服器的記憶體上,Web伺服器的cpu上,Web伺服器與DB伺服器之間的IO開銷上,總而言之不經過一番仔細的分析和艱苦的調試是很難解決效能問題的。甚至當有的時候有些操作確實很耗系統資源的時候,你不得不手工限制這種任務的並發數,變並行為串列,以保障其他動作的運行效率。但經過今天上午的調試,我的這些觀點發生了一點點變化。
  在一個已有的Web系統中,我對其中的一個模組兒進行了重構。這種重構不是為了改善代碼結構或者提高代碼效率,僅僅是改變模組兒中用到的演算法。新演算法和老演算法的效率是相近的,但重構完之後我卻發現系統效能有了非常嚴重的下降,處理同量資料的耗時提高了1000倍!剛開始我很受打擊,檢查了重構中涉及的主要部分的執行流程,沒有發現可疑點。系統佔用的記憶體和以前一樣,迴圈體被執行的次數和以前一樣,和資料庫之間的IO只有一次並且很快,問題到底會出在哪兒呢?最後我採用了最笨的辦法,注釋掉那些我認為可能是運行速度瓶頸的語句,然後逐步縮小懷疑的範圍。最後我在迴圈的第四層找到了這個bug,這是一個不必要的對一個非常重型的方法的調用。要知道,在第三層迴圈中,只有不到5%的情況會進入出現bug的第四層迴圈,所以剛開始我一直沒有懷疑到這裡。但最後就是這倒黴的5%,卻佔用了整個系統已耗用時間的99.9%。
  說的有些羅嗦,其實道理很簡單,恐怕也是我們在剛上大一大二的時候就學過的,那就是不要在迴圈體內放太耗時間的語句。可惜當自己接觸的東西多了,反而把這樣最基本的原則都忘了,寫代碼的時候不夠謹慎,對迴圈體內的方法調用很少考量其執行效率。

  把這個東西放到提問區,是想問問各位大牛,.net下面有沒有比較輕量級的動態測試載入器,能夠分析出給定代碼塊的執行瓶頸?(比如,給出每個語句的執行時間百分比。)

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.