Severe performance penalty when using message box

Sep 5, 2013 at 2:01pm

Severe performance penalty when using message box

Hi
Sorry for the title of the post, it might sound a bit over the top, but I just made a simple performance test using message-boxes with some interesting results:

I do like to use message boxes to store temporarily some data (into the right inlet) and then pass it on with a bang on the left inlet. but this method is not very performativ compared with using a textedit.

Check out this patch:

<code>

– Pasted Max Patch, click to expand. –

</code>

its very simple, banging with metro as fast as possible a long message though a chain of message boxes vs. a chain of textedit boxes.

Running this patch on a 4 year old macbook pro, the result are stunning:

the 8 messageboxes let max soar up to use 75% of my CPU, while the framerate drops to 110.

the 8 textedit boxes use only 10% with 220 fps.

I am surprised that 8 messageboxes in such a simple patch can use up so much system resources (Actually with only 4 messageboxes it uses the same 75% of the CPU, too, but the framerate is better: 220)

so it looks like this unpretentious little gray box is attached to some serious overhead processes in the background.

now I wonder if there are some people that can confirm this find.

and I would like to know where this performance penalty comes from, and what it means for using messageboxes in high preformance patches where high framerates are important.

for me it looks like as if I am going to use textedit from now on in order to have a temporary storage.

#264409
Sep 5, 2013 at 2:11pm

They seem to perform the same for me.

Presumably you do not need the UI elements to update at that sort of rate in order to run your patcher. You may hide UI objects in a sub patcher so that they need not draw, or use zl reg or something to ensure no unnecessary UI drawing.

Cheers

-A

#264411
Sep 5, 2013 at 2:17pm

Hi,

I just ran your patch on an old core2duo 2,8 Ghz, 2Go Ram, built-in video card, and both methods performs at 500fps, with no noticeable change of the CPU load.
But if you find out what causes that behaviour on your setup, I’d be curious to know.

Cheers,
Sylvain

#264412
Sep 6, 2013 at 1:27am

Thanks you for your feedback.

I actually switched them all to hide_on_lock and not_editable. so the UI should have much influence.

My old machine is an unibody 2,4 Ghz Core2Duo, 4GB Ram. Max 6.1.3 32bit with OSX 10.7.5 The test was made straight after startup with no other apps (beside all the little deamons) running in the background.

And I just tested it on a new retina 2,8 Ghz i7 with 16Gb Ram, Max 6.1.3 32bit, OSX 10.7.5 with similar results: 80% with messageboxes and 15% with textbox, and the framerate doesnt get heigher than 230 fps.

#264440
Sep 6, 2013 at 2:27am

somehow it is interesting that messageboxes are slower compared to the textfield, not what you would expect.

but well, it is a GUI object and GUI objects should be removed all from a patch, when is it about speed.

alternatives are zl reg, pack, pak, list, trigger, v, pvar, coll …

-110

#264445
Sep 6, 2013 at 2:50am

how can i change my avatar?
please i need for some help, i can’t find it!!!!!!

#264450
Sep 6, 2013 at 2:56am

You may hide UI objects in a sub patcher so that they need not draw

Does that always help?

– Pasted Max Patch, click to expand. –
#264451
Sep 6, 2013 at 3:00am

@roman: Yes, thats indeed the lesson learned. but the rule is still flaky: textbox is a GUI object aswell…

but as a developer my alarms would go off, since this task is too simple to justify such a CPU performance.

@quantesizer: try gravatar.com

#264453
Sep 6, 2013 at 3:04am

(edit)

never mind… zl.disappointing

– Pasted Max Patch, click to expand. –
#264457
Sep 6, 2013 at 3:28am

@metamix

your patch was faulty, you should have connected the list to the right inlet of “zl reg”.

but the direction was right: even better performance with zl.reg.
80% with messagebox (even hidden inside a subpatcher)
10% with textbox
8% with zl.reg

<code>

– Pasted Max Patch, click to expand. –

</code>

BUT: Further tests showed that in 64bit modus these performance differences do not occur anymore. at least not noticable with the rough measurment tools at my hand.

And since 64 bit is the future this issue just turned into a nonissue… :-/

BUT BUT: what I still wonder is how those 500fps could happen on that old machine of sylvain. mine never got above 220fps.

#264460
Sep 6, 2013 at 3:45am

doh! Whoops.

Curiously.. I don’ t get an 80% to 10% difference between message box and textbox. Not sure how you arrived at that. Either way, it’s somewhat disappointing that zl.reg doesn’t do much better than a text box, no?

#264463
Sep 6, 2013 at 4:35am

I ran the patch on an old Mac mini (C2D, 2Ghz) and get 500fps for both message box and textbox. When replacing ‘qmetro’ with ‘metro’ I get exactly 1000fps for both methods (OS 10.5.8, Max 5.1.9).

#264466
Sep 6, 2013 at 4:48am

@broc: I just ran it on 5.1.9 an got the same results as you did – no differences and no special CPU-load.

and I replaced qmetro with metro and now I get 1000 fps on 6.1.3 32bit as well, but still the same strange CPU load.

@metamax: you also can look at that from the bright side :-)

#264468
Sep 6, 2013 at 8:37am

the difference between [trigger 'a b c'] and [zl reg] would be interesting.
t, f and i, are the base values off one can start benchmarking.

#264492
Sep 6, 2013 at 11:41am

So far I seem to be the only one that observes this phenomenon in 32bit mode. Or has any of you seen any significant differences?

As mentioned above, in 64 bit mode the differences are not as big:

message box: 8.8%
text box: 9%
zl reg: 7.2%
max without metro switch on: 5.4%

so the GUI objects loose.

I would switch over to 64bit mode, but jit.display doesnt work yet and it is an important functionality in my app. And I prefer to know the devil instead of hopeing for an angel. but its good to know that some things run smoother in 64bit than 32bit.

@roman: trigger and zl.reg can not really be compared, since trigger cannot store data, only the values set on instantiation. unfortunatly zl.reg cannot store multiple lists separated by commas, so the message box will stay in use, but I certainly will avoid it more consiously now.

#264516

You must be logged in to reply to this topic.