Something about the way node relationships are tracked and recalculated was changed in Nuke 9 (I think... maybe it was 8), which has resulted in a lot of of strange performance hits from nodes that are out of the evaluation tree. One of the most obvious side-effects of this is that the `Node.dependent()` Python method is now orders of magnitude slower, to the point that it's actually faster to call `.dependencies()` on every single node in the script and intersect their inputs with a given node to find downstream nodes.
I've also got an outstanding bug related to all of this performance stuff: Bug 50719 - 3D system causing UI lockups on upstream nodes -Nathan From: Daniel Hartlehnert Sent: Monday, March 07, 2016 4:04 AM To: Nuke user discussion Subject: Re: [Nuke-users] Nuke locking up with 1 cpu busy I understand. But i have seen it when opening standard grade or merge nodes. These definately didn’t have expressions on them. > Am 07.03.2016 um 09:48 schrieb Ben Dickson <[email protected]>: > > The expressions can be in unobvious places, like inside gizmos. > > The bug Elvis Au mentioned sounds similar to "Bug 35703. Expressions force > tree to validate unnecessarily, when changing unrelated parts of the tree", > which I reported as such: > > On 06/05/13 20:24, Ben Dickson wrote: >> Attached another example, which doesn't involve the RotoPaint: > > >> The ImagePlane gizmo (available from Nukepedia) contains an "width" >> expression in a crop. This combined with the motionblur option in >> the Card3D causes the same UI sluggishness > > >> Adjust the slider in the Keyer node, or try and type something in a >> label - it is noticably laggy. > > >> If the motion blur is setting is set to 0, it is much quicker. > > >> The UI slowness gets progressively worse the more copies of the >> ImagePlane there is, to the point the comp was not workable.. > > >> I haven't tested in older versions, but this behaviour would very >> much explain many of the slowdowns we have experienced in the past.. >> Especially because we automatically create a Crop node above our >> Write nodes, and this contains input.width and input.height >> expressions (to prevent writing out EXR's with oversized bbox) > > >> It seems like a relatively serious bug, as it will exacerbate any >> inefficiencies in any nodes - worse as it can be very hard to track >> down as the cause of a slow script.. > > Attachment was essentially this script: > https://gist.github.com/dbr/2f3faff433d59f58be7d > > Reported for 7.0v5 in 2013 - but remains same in all current Nuke versions. > > Some variant of this is usually the cause of a majority of "my script is > slow" complaints I've seen here - some slow node is upstream of a time-based > node (TimeEcho or lots of TimeOffset's, transform with the "motion blur" > setting enabled, ScanlineRender with many motion subsamples etc) > > The only way I have found to narrow it down is to delete half the script, see > if it speeds up or not, then repeat (using the Keyer slider as a good way of > checking - it's easy to see if the slider control tracks quickly with the > mouse cursor or not) > > This doesn't exactly sound like the original problem Daniel described > (particularly "i can sometimes work in the same script for hours, then > suddenly the symptons start to show up"), although it can be made sometimes > seem quite random if the slowness is in part due to network file access > slowdowns. > > Something similar also happened with a script containing a lot of ReadGeo > nodes loading Alembic .abc geometry with a relatively complex scene hierarchy. > > > On 07/03/16 18:34, Daniel Hartlehnert wrote: >> @Lucy: >> another question though: if it really is the expressions that are >> causing this. how is it possible that nodes that do not have expressions >> in them are causing this behavior? >> Thats the way it was happening for me. I have scripts with many >> expressions in them, but even opening nodes that have none may cause the >> freeze. >> Oh and sending you a scrlpt is unfortunately not possible. NDA reasons >> and its not really reproducable. >> >> Daniel >> >>> Am 04.03.2016 um 17:39 schrieb Lucy Wilkes <[email protected] >>> <mailto:[email protected]>>: >>> >>> Hi Daniel, >>> >>> I've answered on your forum thread. I also wondered whether >>> expressions might be causing this >>> (http://community.thefoundry.co.uk/discussion/post.aspx?f=189&t=120025&p=1008064). >>> >>> If you have a script and repro steps, please do send them in to our >>> Support team so that we can take a look. >>> >>> Regards, >>> Lucy >> >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > -- > ben dickson > 2D TD | [email protected] > rising sun pictures | www.rsp.com.au > _______________________________________________ > 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
