Loading patch so ssslllllllloooooooooooooowwwww


    Apr 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

    • Apr 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 //
      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!
    • Apr 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
    • Apr 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
    • Apr 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.
    • Apr 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
    • Apr 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..)
    • Apr 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
    • Apr 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
    • Apr 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://
      www.cassiel.com
    • Apr 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.
    • Apr 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
    • Apr 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
    • Apr 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
    • Apr 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.
    • Dec 02 2014 | 4:36 pm
      I (once again) stumbled upon this old thread... as I'm trying to reduce huge patch load times as well.
      I was wondering if after 8 years putting an extension to the abstraction is still quickening the process. Are you by any chance using this method?