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

Reply via email to