2011-05-09 18 views
3

我跑了CPROFILE我這個代碼輸出,這是輸出:明確從pstats模塊

% stats 10 
    646493 function calls (524209 primitive calls) in 3.606 CPU seconds 

Ordered by: cumulative time 
List reduced from 260 to 10 due to restriction <10> 

ncalls tottime percall cumtime percall filename:lineno(function) 
    1  0.000 0.000 3.606 3.606 <string>:1(<module>) 
    1  0.007 0.007 3.606 3.606 {execfile} 
    1  0.068 0.068 3.599 3.599 example.py:7(<module>) 
    3  0.000 0.000 3.266 1.089 tree.py:1058(parseString) 
6698/3  0.068 0.000 3.244 1.081 tree.py:2406(do_parse3) 
104813/3 1.084 0.000 3.244 1.081 tree.py:926(_nocache) 
2615/3  0.016 0.000 3.243 1.081 tree.py:2679(internal_parse) 
3602/14 0.712 0.000 3.239 0.231 tree.py:2531(do_parse2) 
    13/8  0.000 0.000 3.229 0.404 tree.py:2876(do_parse) 
2546/20 0.024 0.000 3.218 0.161 tree.py:1003(parse) 

從文檔,

我們定義基本意味着該 電話是不是通過遞歸引起的

那麼我可以安全地得出結論:我的代碼很慢的原因是:

  1. 由於122284遞歸調用。
  2. 最大的遞歸方法是do_parse3 & _nocache
  3. 原始調用不重要&無法進一步優化。

回答

2
  1. 我認爲你不能看時間是否是因爲該方法調用,或由於這些方法中所做的工作中度過。

  2. 我同意。那將是開始微觀優化python代碼的地方。它可能會帶來一些加速,但通常有更好的方法來加速某些給定的任務。

  3. 不是。首先,如果你有一個真正的應用程序,這將顯示你可能想要擺脫的呼叫。我在你的檔案中看到它被稱爲三次;也許它做了三次相同的計算,並且(子)結果可以被緩存。也許最初的(原始)電話會做一些事情來減少孩子們要完成的工作量。

我可以建議看一下調用圖嗎?我爲此使用Gprof2Dot:

gprof2dot.py -f pstats tmp.pstats |點-Tpng -o tmp.png

http://code.google.com/p/jrfonseca/wiki/Gprof2Dot
http://maxy.homeip.net/misc/gprof2dot_example.png

+0

+1 Grpof2Dot,偉大的工具! – 2011-05-10 08:28:32