evanlivingston

I often use int objects in my patchers just to keep an eye on things. does this have a negative effect?

is-it-bad-practice-to-use-superflous-int-objects-in-patchers

Consumes processor cycles and RAM. Not much, but...

Trade off the good development feedback from the int objects vs. their added memory and processor work. Shouldn't even be able to notice it though, unless you are near the limits of processor or memory, and then only if you have *lots* of them in your patch...

Consumes processor cycles and RAM. Not much, but...
Trade off the good development feedback from the int objects vs. their added memory and processor work. Shouldn't even be able to notice it though, unless you are near the limits of processor or memory, and then only if you have *lots* of them in your patch...
ymmv, g'luck...
cfb aka j2k


I use [message] right inlet to "keep any eye on things"; like a local [print] object. I wonder if the CPU cost is the same as [int]? And what if they're hidden in subpatchers?

If they are not in display = less CPU cost. Still, not zero. message would also have a cost: very little if never called, but still a little memory use.

Again, not matter what the cost, while development is ongoing, use any verbose output you need!!

We do not have a "logging level" setting like java commons logger...so we can't toggle use of it off in the code, but any presence of any logging code uses some memory and cpu. The only completely clean way to stop this cost is to remove the log/printing code completely... and if you are totally done with development, and know the code is stable and 'error free' as far as one can know this...well then, *please* remove the debug/log code, as it just wastes cycles and memory.

But if it is anything like my under developed/overused code (heck, i can "mostly use it, most of the time"), leaving the reporting/log/debug in the code is kindness to everyone who has to deal with the code. X-)

So, to 'sumup': it's not black or white, the amount of cpu and memory used varies with amount of verbose reporting set, but generally, it is not enough to worry about, especially until the code is stable and one needs the darn info less, :)

If they are not in display = less CPU cost. Still, not zero. message would also have a cost: very little if never called, but still a little memory use.
Again, not matter what the cost, while development is ongoing, use any verbose output you need!!
We do not have a "logging level" setting like java commons logger...so we can't toggle use of it off in the code, but any presence of any logging code uses some memory and cpu. The only completely clean way to stop this cost is to remove the log/printing code completely... and if you are totally done with development, and know the code is stable and 'error free' as far as one can know this...well then, *please* remove the debug/log code, as it just wastes cycles and memory.
But if it is anything like my under developed/overused code (heck, i can "mostly use it, most of the time"), leaving the reporting/log/debug in the code is kindness to everyone who has to deal with the code. X-)

i dont think you mean int, you mean numberboxes, right?

those should be killed when the patch is ready.

is it bad practice to use superflous int objects in patchers?