Paul Greyson

In a large patch with many controls, I get a SWOD of variable length (up to 30 seconds) when restoring control values using pattrstorage.

Shark shows that a large amount of time is being spent in sched_purgeqelems.

This is a somewhat old version of Max (v4.5)

swod-restoring-a-patch-using-pattrstorage

for starters : check the priority message for pattrstorage ;

you can decide the order in which messages are sent to your pattred elements.

turn interpolations OFF for any GUI that doesnt need any

maybe you can split your UI in several bpatchers having all there own pattrstorage and recalling them one after the other , instead of using one single pattrstorage that stores/recalls everything......

Quote: Paul Greyson wrote on Tue, 22 January 2008 01:34

----------------------------------------------------

> In a large patch with many controls, I get a SWOD of variable length (up to 30 seconds) when restoring control values using pattrstorage.

> Shark shows that a large amount of time is being spent in sched_purgeqelems.

> This is a somewhat old version of Max (v4.5)

for starters : check the priority message for pattrstorage ;
you can decide the order in which messages are sent to your pattred elements.

Quote: Paul Greyson wrote on Tue, 22 January 2008 01:34
----------------------------------------------------
> In a large patch with many controls, I get a SWOD of variable length (up to 30 seconds) when restoring control values using pattrstorage.
>
> Shark shows that a large amount of time is being spent in sched_purgeqelems.
>
> The patch is driven by a qmetro.
>
> This is a somewhat old version of Max (v4.5)
>
> Any help would be appreciated.
>
> - Paul
----------------------------------------------------


I could probably rework the use of pattrstorage. But 30 seconds to restore the patch seems like a bug.

Oh forgot to mention: the problem seems to get worse over time. i.e., when I first start the patch, restore will take maybe 1/2 second. After several hours, I'm at 30 seconds.

I could probably rework the use of pattrstorage. But 30 seconds to restore the patch seems like a bug. 

Oh forgot to mention: the problem seems to get worse over time. i.e., when I first start the patch, restore will take maybe 1/2 second. After several hours, I'm at 30 seconds.


Consider upgrading to 4.6.3 as there have been several bug fixes in the pattrstorage system since 4.5.

I agree with karrrlo, having one pattrstorage for a complex patch is inadvisable. It doesn't have to be heinous, you can create multiple pattrstorages and control certain operations such as read and write like so:

Just don't do a recall on all of them at once! You'll get slowdowns, lost data etc. as you have already discovered.

SWOD restoring a patch using pattrstorage