Initial testing shows that the 1 cpu lockup for 40+ sec is fixed by removing the 'tilecache' folder that the RotoPaint node creates and uses.
For example a 'bad' tilecache directory had 285K items in it, the new 'tilecache' folder that is created automatically works perfectly. OsX, nuke 9.08. On 8 March 2016 at 07:20, Nathan Rusch <nathan_ru...@hotmail.com> wrote: > 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 <dah...@gmx.de> > *Sent:* Monday, March 07, 2016 4:04 AM > *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk> > *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 <ben.dick...@rsp.com.au>: > > > > 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 <l...@thefoundry.co.uk > >>> <mailto:l...@thefoundry.co.uk <l...@thefoundry.co.uk>>>: > >>> > >>> 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 > >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >> > > > > -- > > ben dickson > > 2D TD | ben.dick...@rsp.com.au > > rising sun pictures | www.rsp.com.au > > _______________________________________________ > > 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 >
_______________________________________________ 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
