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

Reply via email to