I have experienced the issue in 6.2, specifically the bug indicated. Python expressions (and possibly tcl but I did not test that) would be executed literally hundreds or more times when the properties panel was first opened for that node. It also would occur when deleting the node.
However when I experienced this it seemed to only happen under out pipeline environment and not in a vanilla launched Nuke so I never followed up on it. In either case however I did notice it getting a lot better in 6.3 and I believe the bug was fixed. From: [email protected] [mailto:[email protected]] On Behalf Of Nico Dufort Sent: Wednesday, October 12, 2011 6:11 PM To: Nuke Python discussion Subject: Re: [Nuke-python] Read nodes, expressions, gizmos Hey John, In the end, I found several factors to our problem, with the gizmo python expression being the smallest one (although I did rewrite it as it was way too much code for what it was doing). The most important factor was external, it seems. That being said, I read this in the release notes of 6.2v4: * BUG ID 16881 - Excessive evaluation of knob expressions occurred in Nuke. We are on an earlier version, and that might, or not, be one other factor explaining some of the things we have witnessed with other expressions which are doing a lot heavier things than set paths and such. I would be curious to hear from anyone on 6.2v3 if they have experienced anything as mentioned in the above. I believe one artist who was on 6.3 reported that things were smoother in that regard, but I can't really confirm. In the end, even though the python was excessive for the simple task, it was not a major part of our problem. Thanks, nico On Thu, Oct 13, 2011 at 8:18 AM, John RA Benson <[email protected]> wrote: Find anything out about this? I built a gizmo that can contain many read nodes. They all use this bit of python in read's file knob to get the filename from a knob (seq) on the gizmo: "[python {nuke.thisParent()['%s'].value()}]" % seq.name() Sounds like something you've got going on? I tried switching to the equivalent tcl code and also using linked knobs for awhile. They each worked, but did not provide any speed improvements. In fact, the node became randomly buggy so I reverted because I was tired of hearing complaints. I also wouldn't say the gizmo is 'slow' at all in it's present state, so I would have to disagree that python is making the user experience significantly slower. Maybe that's not enough py to slow things down? Maybe in your case it's not the python but something that it's executing (say, a walk on the net) that's bogging things down? cheers - jrab On Oct 10, 2011, at 12:02 AM, Nico Dufort wrote: Hi everyone, I wanted to ask about performance issues using [python {blah....}] inside gizmos. Context: a gizmo of nodes with knobs fetching through python expressions a top parent node's info, and a Read with a tcl expression based on the return value from the NoOp python call. Problem: multiply this by 200 hundred, and you get a slow as snail user experience. I'm not familiar with the original setup, and I'm trying to clean this up. Opening my script editor showed me that the python expressions are constantly being evaluated each time a user would interact with a node, upstream and downstream. Madness. I had to put a callback in my own init.py to turn the gizmos off when I load a script just to get some interactivity out of someone's shot. Nonsense. A brief search through the list revealed that using python in Read nodes was really slow. In our case, the python is not in the Read, but the NoOp. As of today, is this still the case, and could that explain the slowness observed? Would a plain tcl expression be faster (albeit the extra text splitting/replacing)? Last but not least, is there a reason for an expression like this to be evaluated all the time? I would understand that it happens when the gizmo is first loaded, but plugging in a viewer to a node above or below should not trigger the evaluation of the expression (no callback involved, I tried the most vanilla Nuke we have to eliminate the callbacks that are part of the environment). Thanks. nico -- "Attention, attention. Here and now, boys," the mynah repeated. "Here and now, boys." _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python -- "Attention, attention. Here and now, boys," the mynah repeated. "Here and now, boys."
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
