|
|
Perf. inspector show interesting stuff Hi, i just noticed, when using Perf. inspector, that Kineme Directory scanner and Structure from file get evaluated every frame, even if the scan signal is set to false, and even if the inputs do not change (nor the outputs). Is that behaviour supposed to be normal ? I don't see why these patches should be eval. each cycle... As a sidenote, and not KnM related, i also noticed that the pulse patch (normally hidden) eats up CPU, as it is also eval. every frame, as is the Smooth patch (even if inputs are not changing)
|
Directory Scanner and Structure From File are both old patches -- we probably made mistakes to have them eval each frame (back when we were aiming mostly at functionality, not so much at efficiency).
Small detail: a False input can't disable a patch (as in the scan signal to directory scanner) -- only if the outputs are all disabled, or an enable-input is False. The patch otherwise has to execute to see if the false signal is in fact false, and do nothing (adding an execution, but not incurring large amounts of CPU use). (if it isn't set to execute only when inputs change, that is)
Also, when testing, be sure that all inputs are actually disconnected to see if the patch in question executes each frame -- I've seen a few patches that execute every frame when their inputs are attached to certain patches (even non-executing ones!) -- for example, javascript -> path of built-in directory scanner = directory scannerruns every frame for some reason (even if the string doesn't change).
Thanks for the notes, I'll try to update those patches for the next release.
I've Also (unrelatedly) noticed that adding completely disconnected patches to macros (i.e. enter a macro, create a math expression patch, leave the macro) causes them to eat up a few fractions of a percent more cpu... so one way to speed up macros/iterators seems to be pulling as many patches out of them as possible (even non-executing patches seem to add to the load)... once I've done some more conclusive analysis, I'll post more details on this.
understood. but now that you released Perf. inspector, it just emphasizes efficiency issues....
yeah, that's why it exists -- in part, to see which of our patches are lame, and also to find out general patterns to make high-performance compositions.
Wasn't complaining about your observations, or trying to make excuses -- just an explanation :)
If you find other misbehaving patches, feel free to post them as well -- I'm hoping one day to add a portion to the wiki with quantifiable performance notes (in part, driven by this tool)