[Performance] 最近查 memory leak 有感…

[Performance] 最近查 memory leak 有感…

idea最近一直在查不同專案的 memory leak 問題…

真是覺得查 leak 這件事情,相當的不容易…

 

記得從一開始工作的時候,傾向使用不用動到程式碼的工具,

來幫忙找 leak,基本上是因為懶惰,

另一方面也是工具通常會有成效~

最一開始用的工具叫什麼名字已經忘記了,

它可以用漂亮的介面將哪邊 leak 了多少,清楚的列出來~

雖然也是會有些奇怪的誤判,但通常無傷大雅,

因此我很開心的用了這工具好一段時間~

 

後來好一陣子沒有需要查 leak,結果又發現了 leak 的問題,

直覺想到用之前的工具,卻發現它沒能成功的找出 leak 的地方…

試了幾次都不成功,失望之餘只好求助於別的工具~

這時候開始嘗試微軟自己的 xperf,

也解掉了一些 leak 的問題,覺得相當的不錯,

想說這應該就是就是最好的武器了~

 

沒想到這最好的武器沒多久就受到了挑戰,

在查一個 leak 的時候,發現它找出了 leak,

卻只能指出 leak 在 ntdll 裡面… 這對我的工作進展毫無幫助…

這時候我改嘗試微軟的另外一個工具 DebugDiag,

它在同樣的問題上,能指出有 leak 的地方,

看起來似乎是有用的….

然而,它指出來的地方卻是一個已經被釋放掉的 DLL,

這又讓我的工作停滯不前…

 

正當我開始有點想用需要動到程式碼的工具來幫忙查的時候,

突然間發現,自己去修改程式碼,也可以縮小 leak 的可能範圍~

基本上因為大致知道做什麼事情會發生 leak,

因此就把那附近的程式碼都註解掉,試試看會不會 leak,

不會的話就又多放一些程式碼出來,看看是不是那段的問題~

神奇的是,用這個方法,蠻快就確定了這次的 leak 問題的起因~~

 

幾經波折,終於解決了這次的 memory leak…

其實工具與方法應該是沒有好壞的,只是覺得,

自己應該要可以適時的挑選比較適用的工具與方法,

而不是一直使用「之前用起來很不錯的」方式~

算是一個提醒吧~~

(本頁面已被瀏覽過 12 次)

發表迴響

你的電子郵件位址並不會被公開。