Max 5 really slow loading/creating patches
I was playing around with Max 5 a bit and have a project consisting of tens (maybe hundreds) of patches, patches in patches, bpatches, lots of graphics/picts, etc.
These patches are loaded/created during a sort of startup phase in the main patch. There are about 20 main patches which are being created with messages send to a ‘thispatcher’. These main patches contain other patches, create more patches etc etc.
When I start the main patch it takes about 40 secs in Max 4.6.3 to load and create all of this….(on an Intel Dual Core 6600 @ 2.4GHz, 2GB, XP, sp2)
Now I’ve converted ALL of them into the new max 5 world, cause things simply wouldn’t start at all otherwise, the average patch has grown about 5/10 times in size by doing so.
Now when I start the main patch I’ve waited for about 1.5 hour, and it still hasn’t got loaded/created everything yet. It hasn’t crashed, its still loading/creating patches, but it does so unbelievable slow.
I find it hard to believe it makes such a big difference (it only took 40s in Max 4) . I know it’s difficult to say anything about it without seeing the exact patches, but I was wondering if more people are experiencing the same problems?
Ok, I’ve been trying to focus down on the problem I’m seeing with creating patches. It seems like it is related to patches opened/saved in other patches and the number of ‘pv’ objects in the patch.
To clarify things I’ve attached a zip file with 2 folders (‘max4_test’ and ‘max5_test’). There are 3 patches in each folder, I’ve created the patches with Max 4.6.3 and then resaved them for the Max5.0.1 format.
This is the main patch, it creates 9 ‘test.(max)pat’ in a row. There is a bang at the top of the patch to start the process.
This is a patch which holds 3 ‘patch_inside_test.(max)pat’.
This patch is holding 12 pv’s with the same name.
When I run the ‘tester.pat’ in Max 4.6.3 and click on the bang it takes about 0.5 sec to complete the whole thing.
When run in Max 5.0.1 it takes about 10 secs!!
There seems to be a direct relation between the number of pv’s in ‘patch_inside_test.maxpat’ and the time it takes to create all these patches.
I didn’t really test it, but there seems to be slight improvement with version 5.0.1 but still doesn’t seem right.
Any insight in what is going on would be nice.
i don’t really have much insight into what you’re particular problems might be, however, if your load time is that long, you may be pushing the limits of what max is meant to handle.
it might be time to take a look at some additional languages offered by max, MXJ being the first one that comes to mind. sounds like you could really benefit from bringing some of those pvars into a real data structure.
just a thought
First time clicking the button in 4.6.3 is 414ms, in 5.0.1 it is 600ms.
However, as I continue to click the button, or open another patcher and do it, the time starts to increase rapidly. I assume this is probably what you are seeing. We love fixing optimization problems like this.
i get 400 ms in Max 4.6.3 and 21 seconds in 5.0.1.
i’ve noticed this in my patches too that scripting new objects takes much much longer in max 5. not so bad if scripting 1 new object, but when scripting many, it can turn into a serious waiting game. however, i’m not so sure about the pv object being the culprit, as i don’t use it at all.
os 10.5.2 2.33 Intel Core 2 duo macbook pro 2 gigs ram
On Apr 28, 2008, at 5:14 PM, jake rodriguez wrote:
> i get 400 ms in Max 4.6.3 and 21 seconds in 5.0.1.
> i’ve noticed this in my patches too that scripting new objects takes
> much much longer in max 5. not so bad if scripting 1 new object, but
> when scripting many, it can turn into a serious waiting game.
> however, i’m not so sure about the pv object being the culprit, as i
> don’t use it at all.
The example posted was definitely a pv issue and we should be able to
dramatically improve this for a future incremental release. Thanks for
the very clear example, So9.
Jake and other people with specific performance issues, if you post
some clear examples, we will be looking at them over the next little
while to try and improve performance where it makes sense for us to do
so. Some places we have to take a higher cost due to the
infrastructure changes that makes many of Max 5’s new features
possible, but where this is not the case, we’ll be working hard to
Thanks for the quick response, hope it will be fixed soon.
Forums > MaxMSP