+1 to know the answer to that... definitely have read about avoiding redraw objects (using [i] instead of [number] for example). Also hide/show--with a bunch of multisliders hiding/showing I saw a performance improvement, but didn't do any real benchmarking.
Then of course there's the "performance decrease" that you SEE in an object, versus the REAL performance decrease (actual slowing of the output lists from multislider, for example...dropped values...etc.)
I would really really like a reference somewhere of the performance hits that the various objects have, graphical or not. So I could weigh options like effects etc. I realize that a given object could be very "light" or very "heavy" depending on how it's used (and how big its data set is), but some overall guidelines would be great to keep in mind while designing.
Even a simple, generalized three-column table of objects rated light, medium, heavy would be a great start.
When an object is hidden or a in a hidden patcher, its paint method (that the part which "draws to the screen") doesn't get called at all. Of course if you wanna be picky, there's still an overhead since there's some logic to know if the object is visible or not which has to take place but I would be really surprised if the overall performances would suffer from that.
One other thought, how about UI objects that are in the patch or subpatcher, and not hidden, but the window is scrolled so they're not actually on the screen? Are they still painted, or does Max know they're not visible---using a patching_rect versus window-scroll position, or something?
Wondering if in this case, the paint method is called, but it takes up less resources as there's no visible "target" that actually changes things on the screen.