According to the bug it was submitted by Sean Looper.
On 4 Sep 2015, at 11:54, Howard Jones wrote: > Hi Ben > > Does this relate to the script I sent in then where the one slate / write > combination could slow down a script? Or is that a different bug? > > Howard > > On 4 Sep 2015, at 12:12 pm, Ben Woodhall <[email protected]> wrote: > >> Hi Elvis, >> >> I'm afraid that re-evaluating expressions on changing the tree is >> deliberate. Nuke does not yet track dependencies for expression evaluation >> (in spite of the expression arrows). This means that any changes in the >> tree can potentially change any other knobs (via an expression link). >> >> Bug 16881 related to animated knobs which were being re-evaluated several >> times per context (frame or tree change). If your expressions re-evaluate >> more than once per context then this is a recurrence of bug 16881. If your >> expressions re-evaluate once per context then I recommend that you raise a >> feature request for tracking dependencies to avoid re-evaluating nodes which >> are independent of modifications made in the tree (nodes, knobs or >> connections). >> >> We are aware that this can have significant performance issues with heavy >> scripts/nodes and are keen to hear from any other users who also have >> problems with performance when making minor modifications to big scripts >> (judged by the size of the nuke script or heavy use of expressions). >> >> Let me know if you need a hand getting the information out of your scripts. >> >> Thanks, Ben Woodhall >> >> >> On 3 Sep 2015, at 21:38, Elvis Au wrote: >> >>> >>> I reached out to nuke support and it sounds like something similar was >>> fixed in 6.2v4 (bug#16881) but may have resurfaced. But to confirm I'm >>> sending them code samples. I can replicate the tcl python code in the knobs >>> of all nodes getting triggered whenever anything in the script is changed. >>> (Today I noticed that typing in a backdrop note triggered the tcl python >>> code with each keypress...) >>> >>> So even if my python was light and zippy, in a large script with thousands >>> of nodes all trying to execute python code, the gui will lockup until it >>> gets through it all. I don't want to go down the path of restructuring >>> all our code quite yet until I get word of whether this is can be fixed or >>> not. But I'm hoping to get this sorted out since it is painful to work >>> like this. >>> >>> Also I tried this in Nuke 9.0v7/linux. >>> >>> >>> From: "Michael Garrett" <[email protected]> >>> To: "Nuke user discussion" <[email protected]> >>> Sent: Thursday, September 3, 2015 12:37:00 PM >>> Subject: Re: [Nuke-users] python expressions locking up the gui >>> >>> I'd say it's largely because of the evaluation of the python via tcl code >>> in the knobs. As long as the functionality is retained, the code needs to >>> be migrated from being constantly executed within the knob to being a >>> module that loads the function once when Nuke starts up or when a node is >>> generated - eg/ callbacks such as knobChanged, onCreate and onScriptLoad. >>> >>> I've been in this scenario before, and it is hellish trying to get any work >>> done! But some cleanup of the python environment should make things a lot >>> more zippy. >>> >>> Cheers, >>> Michael >>> >>> On 26 August 2015 at 11:31, Elvis Au <[email protected]> wrote: >>> Hey all - >>> >>> On particularly large nuke scripts, I'm seeing the scripts lock up for a >>> few seconds before regaining interactivity in the gui. >>> Digging into it, I found that we have a lot of python code (embedded in tcl >>> eval code in knobs) which all seem to have to execute any time I make any >>> update (add/remove a node, change a knob, attach/disconnect a noodle, etc) >>> And on larger scripts, because there's more of this code that has to be run >>> through so the lag feels worse. I can see the expressions fly past if I >>> have the script editor open and when the it's done printing out, the script >>> becomes responsive again. >>> >>> In a test, we removed the python expressions and everything is zippy again. >>> But this seems excessive that all this code is triggered all the time when >>> any change is made, upstream or downstream. Is there a rhyme or reason to >>> this? Has anyone seen this before? Any insights? >>> >>> Also I'm 8.0v6/linux. >>> >>> thanks! >>> Elvis >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> -- >> Ben Woodhall >> Software Engineer >> The Foundry Visionmongers Ltd >> 5 Golden Square >> London, W1F 9HT >> Tel: +44(0)20 7473 4350 >> Web: www.thefoundry.co.uk >> Email: [email protected] >> >> The Foundry Visionmongers Ltd. >> Registered in England and Wales No: 4642027 >> >> >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users -- Ben Woodhall Software Engineer The Foundry Visionmongers Ltd 5 Golden Square London, W1F 9HT Tel: +44(0)20 7473 4350 Web: www.thefoundry.co.uk Email: [email protected] The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
