使用性能計時器
在Nuke中打開性能計時器時号俐，就可以通過Python讀取性能信息皆怕。就能知道每個節(jié)點的運算時間妇智。
在調(diào)試運行較慢的腳本磷杏，找出耗時瓶頸上很有幫助。
注意憋活，打開性能計時器會影響Nuke的性能堕虹，因為會頻繁打開卧晓、關閉計時器，同步線程赴捞。因此打開
此功能逼裆，Nuke會更慢，但是能讓你獲取nuke腳本處理時間的快照赦政。
從命令行加上“-P” 會打開此功能胜宇，或者調(diào)用Python命令來打開計時器
nuke.startPerformanceTimers()
檢查計時器是否允許性能計時器：
nuke.usingPerformanceTimers()
關閉計時器：
nuke.resetPerformanceTimers()
Nuke架構上的注意事項
當nuke內(nèi)的節(jié)點要渲染時，有4個步驟：
- store -- 第一件事就是存下用戶在knobs上選擇的數(shù)據(jù)
- validate -- 節(jié)點告知Nuke其輸出的信息恢着，例如處理的哪個通道桐愉，以及大小
- request -- 在這節(jié)點弄明白了其需要哪些輸入才能產(chǎn)生對應的輸出（例如，需要通道掰派，需要區(qū)域）
- engine -- 在這節(jié)點干了大部分的工作从诲，并輸出。這也是花費時間最多的地方靡羡。
更多信息盏求，請看nuke 開發(fā)文檔
通過python獲取能耗時間
Nuke的性能計時器收集這四個處理階段的信息，并可以通過python來獲取亿眠。另外，性能計時器激活時磅废，
計時信息會顯示在節(jié)點圖中纳像。節(jié)點也會根據(jù)耗時比重顯示不同的顏色，從綠（最快）到紅（最慢）拯勉。
函數(shù)nuke.node.performanceInfo()會打印某個節(jié)點的時間信息竟趾。例如，下面的代碼段就能
打印當前節(jié)點樹種每個節(jié)點的時間信息（包括在 組內(nèi)的節(jié)點）：
for n in nuke.allNodes(recurseGroups=True):
print n.fullName()
print n.performanceInfo()
對一個簡單的只有 Checkerboard-> Blur -> Defocus -> Viewer 的節(jié)點樹輸出和下面的很像：
Defocus1
{'callCount': 10228, 'timeTakenWall': 28524348, 'timeTakenCPU': 624512794}
Blur1
{'callCount': 9607, 'timeTakenWall': 9906815, 'timeTakenCPU': 151406143}
Viewer1
{'callCount': 0, 'timeTakenWall': 0, 'timeTakenCPU': 0}
CheckerBoard1
{'callCount': 34396, 'timeTakenWall': 3923322, 'timeTakenCPU': 29982254}
如上 nuke.Node.performanceInfo()返回了一個包含下列性能統(tǒng)計信息的字典：
- callCount 這個過程被調(diào)用的次數(shù)
- timeTakenWall 用墻上掛鐘記錄所花費的時間宫峦，用戶實際要等待此處理要結束的時間岔帽。以毫秒計算。
- timeTakenCPU
- Linux上是CPU執(zhí)行代碼的時間导绷，也是毫秒計時犀勒。是所有CPU上的用時總和。例如，多線程engine
的處理時間就要比實際用時長很多贾费。如果平均CPU時間（timeTakenCPU初始使用的線程數(shù)）比每個線程執(zhí)行
時間短钦购，說明CPU線程花了很長時間但沒有執(zhí)行代碼。例如褂萧，等待鎖押桃，說明性能又問題。 - MAC和Win上导犹，CPU時間還不能用唱凯，Mac上這個值和處理的總時間差不多。
- Linux上是CPU執(zhí)行代碼的時間导绷，也是毫秒計時犀勒。是所有CPU上的用時總和。例如，多線程engine
在Linux Nuke開24線程上獲取的時間信息谎痢，我們看下最耗時的兩個節(jié)點Blur和Defocus：
Defocus1
{'callCount': 10228, 'timeTakenWall': 28524348, 'timeTakenCPU': 624512794}
Blur1
{'callCount': 9607, 'timeTakenWall': 9906815, 'timeTakenCPU': 151406143}
Blur節(jié)點的CPU時間是 wall time的24倍磕昼，Defocus節(jié)點的CPU時間是我們期望值的三分之二。說明engine的線程
都被Blur節(jié)點占用了舶得，同事Defoucs節(jié)點花費了相當長的時間來等待掰烟，同時我們也發(fā)現(xiàn)了以后優(yōu)化Nuke的一個方向！
其他性能統(tǒng)計
默認沐批，nuke.Node.performanceInfo()會給出engine處理部分,通常也是最好是部分的用時信息. 也可以
通過傳入下面的參數(shù)獲取其他處理部分的用時信息:
nuke.PROFILE_STORE
nuke.PROFILE_VALIDATE
nuke.PROFILE_REQUEST
nuke.PROFILE_ENGINE
例如,獲取Defocus節(jié)點在上面的數(shù)中的所有用時,可以用下面的代碼:
n = nuke.toNode("Defocus1")
print "Defocus1"
print "Store"
print n.performanceInfo(nuke.PROFILE_STORE)
print "Validate"
print n.performanceInfo(nuke.PROFILE_VALIDATE)
print "Request"
print n.performanceInfo(nuke.PROFILE_REQUEST)
print "Engine"
print n.performanceInfo(nuke.PROFILE_ENGINE)
結果如下:
# Result: Defocus1
Store
{'callCount': 108, 'timeTakenWall': 6571, 'timeTakenCPU': 6563}
Validate
{'callCount': 53, 'timeTakenWall': 1451, 'timeTakenCPU': 1445}
Request
{'callCount': 108, 'timeTakenWall': 1017, 'timeTakenCPU': 1009}
Engine
{'callCount': 10228, 'timeTakenWall': 28524348, 'timeTakenCPU': 624512794}
正如預料的,Defocus大部分時間花在了engine處理上,store,validate,request相對都很快.
如果并非如此,或者callCount顯示store,validate,request調(diào)用次數(shù)很多,就說明這
是一個影響性能的問題了.
注意某些節(jié)點就是要比例子中的Defocus在store,validate,request階段花費更多時間.例如,
reader在validate階段更長,因為需要打開文件,如果是網(wǎng)絡文件就會更慢. ScanlineReader節(jié)點
是另一個例子,validate要更長,同事store節(jié)點比RotoPaint更慢,因為需要bake曲線.帶有耗時
表達式的knbo也會在store節(jié)點花費更多時間.
性能信息寫入XML
當使用 "-Pf <filename>"參數(shù)運行nuke時,性能數(shù)據(jù)連帶部分系統(tǒng)數(shù)據(jù)會自動寫入XML文件.
此模式下,性能計時器會再渲染開始前啟動,渲染結束后就講數(shù)據(jù)寫入xml文件. 當nuke在
此模式運行時,調(diào)用:
nuke.performanceProfileFilename()
會返回xml文件名纫骑。
