-------------------------------------------------------------------------------- The knobChanged knob can be useful in some cases, as it allows you to package your knobChanged code with a Nuke script or gizmo, rather than having to include external registration and callback code. However, if you’ve got an established pipeline, external registration is easier to manage and maintain, on top of being more efficient to execute.
I don’t know the details of how the knobChanged knob’s code is executed, but if I had to guess, I would expect that every time the callback fires, Nuke fetches the code string from the knob and passes it to the Boost Python exec function, which leads to the code string being byte-compiled and executed by the embedded interpreter. Compare this to the standard callback registration approach, where all of the callback code is implemented in actual Python modules, and thus byte-compiled once at runtime. All Nuke has to do in that scenario is call the main entry point, which I would expect to be a static reference to a Python object. So, given equivalent code running in the two different scenarios, it isn’t particularly surprising that the pre-registered callbacks perform better, even though the callback fetching and execution code is all pure Python. -Nathan From: Michael Garrett Sent: Wednesday, March 06, 2013 3:30 PM To: Nuke Python discussion Subject: [Nuke-python] efficiency of knobChanged hidden knob Since it's been around for some time now, I'd be interested to hear what others feel about using the knobChanged hidden knob in a gizmo, considering how often it gets triggered. I've found that even a basic conditional for disabling a knob if a checkbox is on, can slow Nuke down if there are a few instances of this node. This really makes it seem unacceptable to use. Should I look at using knobChanged functions defined in the plugin path instead? It makes the case for learning to write plugins seem more compelling since all that kind of stuff all seems to come "for free". Thanks, Michael -------------------------------------------------------------------------------- _______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
