Hi Nathan, Thanks for the detailed reply! Obviously the packaging into a gizmo/group is a very nice portability convenience but I should look more into using python modules instead. As you said, it loads once when Nuke is launched.
Michael On 7 March 2013 00:54, Nathan Rusch <nathan_ru...@hotmail.com> wrote: > ------------------------------ > 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 <michaeld...@gmail.com> > *Sent:* Wednesday, March 06, 2013 3:30 PM > *To:* Nuke Python discussion <nuke-python@support.thefoundry.co.uk> > *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 > >
_______________________________________________ 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