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 <woodh...@thefoundry.co.uk> 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" <michaeld...@gmail.com> >> To: "Nuke user discussion" <nuke-users@support.thefoundry.co.uk> >> 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 <el...@blueskystudios.com> 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 >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, 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: ben.woodh...@thefoundry.co.uk > > The Foundry Visionmongers Ltd. > Registered in England and Wales No: 4642027 > > > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
