maybites

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.

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.

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:

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.


severe-performance-penalty-when-using-message-box

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.

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.

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.

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.

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 ...

please i need for some help, i can't find it!!!!!!

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


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

@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.

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)

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.

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

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. 

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


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?

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?


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).

@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 :-)

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

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


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.

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.


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:

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.

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? 

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

@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.


Severe performance penalty when using message box