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

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

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.

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

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

Does that always help?

...

@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

(edit)

never mind... zl.disappointing

@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

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.

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?

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

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:

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.