Max performance degradation with UI objects: can you explain that?
The left outlet of uzi doesn't send a bang once at end of the loop but at each iteration.
Here's some more stuff you didn't want to know. You can thank me later:
Wow I opened your patch on my Max7
and then everything in my computer got very slow.
Closing the patch didn't help
Tried to close Max7
Had to crash it.
Probably part of the reason why we have so
much problems ourselves with just saving a patch.
@broc
Indeed! Seems like I'd overworked a bit and mixed up the outlets in my test…
@mzed
Omg, they load the CPU even when hidden, so it's not just the drawing routines. Thanks!
Really? They take more than a few milliseconds, but no major load here. What are your scheduler settings?
@mzed
I had two times less value with subpatched in your test, here are my numbers: 187, 82, 8.
But wait, your test has one flaw—it first resets *all* timers and then executes tests one-by-one, thus the performance metric accumulates readings of the previous test. I fixed it and got values 105, 71, 8—but anyway it is interesting, how UI object consumes the CPU even when it's not redrawing on the screen.
The corrected test:
Thanks. On your new one, the middle timer wasn't completely wired:
I think this just renforces how unreliable this test method is.
I like the version with the message box, too: