Forums > MaxMSP

Loading patch so ssslllllllloooooooooooooowwwww

April 14, 2006 | 4:40 am

Hi all,
Need some input from the community here. I have a patch that is pretty freakin’ huge (like 5 years of work/research huge), and well…it now takes about 5 minutes to load. Has anybody noticed any objects or programming habits that seem to increase (or streamline) loading time? Abstractions with or without extensions? polys~? (I have 2 big ones in my application). bpatchers? too many loadbangs? Too many panels? Being stupid enough to take on this project in the first place? All of the above?

Any advice would be greatly appreciated.

Much thanks,
David


April 14, 2006 | 5:31 am

yeah, a lot of that stuff can slow things down.

Josh Goldberg gave me some good advice on managing my patch,

load things in order, not all at once. get rid of loadbangs besides
one and run off of that, and have loaded subpatcher initialize one
another serially rather than in parallel, but make sure to wait till
one has finished loading/running its init scripts before triggering
the next in line. Ive noticed having a lot of JSUI items really
slows down my patch loading. I had to spend a decent amount of time
looking at the output of top to watch ram usage grow, and manage the
JSUI items so I dont start paging.

too many bpatchers can slow things down as well, which pisses me off,
as it limits the amount of modularity you can .. effectively create w/
o max getting too cranky.

v a d e //

http://www.vade.info
abstrakt.vade.info

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I
LIVE! I LIVE! I LIVE! I LIVE!

You will not be saved by the Holy Ghost. You will not be saved by the
God Plutonium.

In fact, YOU WILL NOT BE SAVED!


April 14, 2006 | 10:13 am

david beaudry wrote:
> Any advice would be greatly appreciated.

I bet you have an unresolved alias within your search path. Then the Mac
OS will wait ca. 5 minutes until it will give up, and Max waits for the
OS to tell that its not there. Very annoying.

To test, attach all servers you did use in the past and see if it loads
faster.

Stefan

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

————————-x—-
–_____———–|———–
–(_|_ —-|—–|—–()—-
– _|_)—-|—–()———–
———-()————x—–

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


April 14, 2006 | 2:19 pm

Yeah…that can certainly be a problem! But unfortunately…not the case here. Thanks for the suggestion, tho. But that’s why I am thinking that I might need to add extensions to all my abstractions? (btw: this is on a mac, if that helps)

Cheers,
David


April 14, 2006 | 4:10 pm

I could probably optimize the hell out of your patch if you wanted someone who has done quite a lot of "that" and found really good ways to do it though. If its a big mess maybe you could pay me for a few days work to get it sped up, probably dramatically. I have done quite a few of these sorts of projects.


April 15, 2006 | 2:49 am

This was a little while ago and may have changed, but I seem to
recall that Tim Place and I found that adding the extension to the
abstraction name loaded into a bpatcher seemed to speed up loading
substantially.

It’s worth a shot.

-Jesse Allison


April 15, 2006 | 11:54 am

I am trying to split up our (big, 2 years research) patch in multiple parts. Not every part is needed during a performance, a big part consists mainly of user interface objects for debugging. If max would crash when the performers are on stage it is essential that the patch won’t take 1:30 minutes to load (as it does now).

I am curious about the abstraction extensions. Why could that possibly make a difference? I will try it though.

Another reason to exclude as many UI objects as possible in the performance part of the patch is that the Jitter framerate depends on the amount of updating UI objects (including the ones that are not visible). Anyone else experiences this? (maybe I should make this a separate topic..)


April 15, 2006 | 12:59 pm

On Apr 15, 2006, at 7:54 AM, Mattijs Kneppers wrote:
> I am curious about the abstraction extensions. Why could that
> possibly make a difference? I will try it though.

Jesse is remembering right. It has to do with the way Max searches
for things and support for a time when we didn’t need such
extensions. I think Tim figured out through some trials that when
you don’t specify an extension, Max searches through all available
search paths for the name as you typed it. Only afterward does it
try adding an extension and looking again. Or maybe it was the other
way…

Anyway, you can save yourself load time if to put an extension on the
patch to be loaded and type the extension in your object box or
bpatcher. When you have 1 or 2 it doesn’t matter. But the more
times this process repeats, the slower loading a patch takes.

—–
Nathan Wolek
nw@nathanwolek.com

http://www.nathanwolek.com


April 15, 2006 | 1:56 pm

>On Apr 15, 2006, at 7:54 AM, Mattijs Kneppers wrote:
>>I am curious about the abstraction extensions. Why could that
>>possibly make a difference? I will try it though.
>
>Jesse is remembering right.

just tried it with a patch i am working at. adding .pat in only 15
bpatchers (some are copies of the same patcher) speeds up the loading
time

I did not yet replaced all the patchers to be used in Bpatchers by
.pat versions, but it already does a difference

great

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com


April 15, 2006 | 2:33 pm

On 15 Apr 2006, at 13:59, Nathan Wolek wrote:

> Anyway, you can save yourself load time if to put an extension on
> the patch to be loaded and type the extension in your object box or
> bpatcher.

On my system (Mac), the bpatcher inspector browser puts ".mxt" or
whatever on the filename, so I tend to leave it there, but for
abstractions I leave off the extension and it works fine. (All my
patcher files are text.)

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com


April 15, 2006 | 3:12 pm

Quote: lists@lowkeydigitalst wrote on Sat, 15 April 2006 06:59

> Jesse is remembering right. It has to do with the way Max searches
> for things and support for a time when we didn’t need such
> extensions. I think Tim figured out through some trials that when
> you don’t specify an extension, Max searches through all available
> search paths for the name as you typed it.

from what i know max always searches through the
whole search path, what else?

the trick is not to put too much rubbish in the
search path but only extensions and of course ones
custom project files.

> Anyway, you can save yourself load time if to put an extension on the
> patch to be loaded and type the extension in your object box or
> bpatcher.

this sounds weird to me, because it should not be
neccessary to tpye "foo.mxb" to load foo.mxb,
creating a "foo" object will load any (=the, assuming
you try to avoid to have double names) file named foo.

but however, you guys are probably right that this
5 minutes load time we re talking about here must be
something about paths and stuff. a patcher can not
take so long to load and process i think unless
someone is using delays behind loadbangs or
megabytes of java and scripting to initialize.


April 15, 2006 | 5:59 pm

On Apr 15, 2006, at 11:12 AM, Roman Thilenius wrote:
> this sounds weird to me, because it should not be
> neccessary to tpye "foo.mxb" to load foo.mxb

It’s not necessary, just faster. Again, Tim essentially came to this
method after running a bunch of tests during Hipno development. It
was very necessary that we get some of the load times on the plug-ins
down.

—–
Nathan Wolek
nw@nathanwolek.com

http://www.nathanwolek.com


April 15, 2006 | 9:55 pm

On 15-Apr-2006, at 14:59, Nathan Wolek wrote:

> On Apr 15, 2006, at 7:54 AM, Mattijs Kneppers wrote:
>> I am curious about the abstraction extensions. Why could that
>> possibly make a difference? I will try it though.
>
> Jesse is remembering right. It has to do with the way Max searches
> for things and support for a time when we didn’t need such
> extensions. I think Tim figured out through some trials that when
> you don’t specify an extension, Max searches through all available
> search paths for the name as you typed it. Only afterward does it
> try adding an extension and looking again. Or maybe it was the
> other way…

Since explicit foo.pat & foo.mxb are faster than implicit suffixes,
your first analysis must, logically, be the correct one.

Another reason for being explicit with the suffixes is backwards
compatibility. If you need to write a patch w/abstractions that you
will share with people running on OS 9-or-earlier, Max won’t even
dream of matching [foo] to a file named foo.mxt. It will match
[foo.mxt] to a file with that name on any Max from 2.2 to the current
day.

Also, since about 100.00000000% [+/- 2] of the people I work with
also use Photoshop, using the .pat extension seems like a really bad
idea. YMMV, however.

– P.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter

iCE: Sequencing, Recording & |home | chez nous|
Interface Building for |bei uns | i nostri|
Max/MSP Extremely cool http://www.castine.de

http://www.dspaudio.com/


April 16, 2006 | 5:43 am

Peter Castine wrote:
> Also, since about 100.00000000% [+/- 2] of the people I work with also
> use Photoshop, using the .pat extension seems like a really bad idea.

You can correct your numbers (I use Gimp ;-) but its a good point, I
always used .pat, because thats the only extension I can savely
remember… and I do not need to remeber if I saved it as text or as
binary… I think Max doesn’t care if its .pat, .mxt or .mxb, but that
would slow down things again, if its a not matching extension…

Stefan

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

————————-x—-
–_____———–|———–
–(_|_ —-|—–|—–()—-
– _|_)—-|—–()———–
———-()————x—–

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


April 16, 2006 | 8:26 pm

On 16-Apr-2006, at 7:43, Stefan Tiedje wrote:
>> Also, since about 100.00000000% [+/- 2] of the people I work with
>> also use Photoshop, using the .pat extension seems like a really
>> bad idea.
>
> You can correct your numbers (I use Gimp ;-)

You’re accounted for in the square brackets.

Frohe Ostern.


Viewing 15 posts - 1 through 15 (of 15 total)