bkshepard

I have a large standalone that uses a number of patchers as subwindows that the user opens and closes while running the application. When the application first opens and DSP is turned on, the subpatchers open very quickly. However, as the application continues to run, it takes longer and longer to open the subpatchers. After the application has been running for an hour or so, some of the subpatcher windows can take several minutes to open. Everything seems to work fine, but it just takes an incredibly long time to open the subpatchers.

Does this sound like a memory leak in my app? If so what kinds of things do I need to look for to try to fix it? I'm not using any 3rd-party externals. Thanks.

Does this sound like a memory leak in my app? If so what kinds of things do I need to look for to try to fix it? I'm not using any 3rd-party externals.  Thanks.


does-this-sound-like-a-memory-leak

Out of curiosity, once the windows start taking a long time to open, are there noticeable differences with Overdrive on or off? Also, if you turn off DSP, do they respond quickly again?

seejayjames wrote on Fri, 25 September 2009 12:30

Out of curiosity, once the windows start taking a long time to open, are there noticeable differences with Overdrive on or off?

No, overdrive doesn't seem to make a difference.

Also, if you turn off DSP, do they respond quickly again?

Also, once the window has been opened and closed, it opens again quite quickly--even if DSP is on--if you open it soon after closing it. However, once time has passed again, it's back to being a slow poke!

I've also kept Activity Manager open and the app doesn't seem to be increasing the amount of memory in use nor the percentage of CPU load as time passes--they both remain pretty constant.

seejayjames wrote on Fri, 25 September 2009 12:30Out of curiosity, once the windows start taking a long time to open, are there noticeable differences with Overdrive on or off?

Quote:Also, if you turn off DSP, do they respond quickly again?

Also, once the window has been opened and closed, it opens again quite quickly--even if DSP is on--if you open it soon after closing it.  However, once time has passed again, it's back to being a slow poke!

I've also kept Activity Manager open and the app doesn't seem to be increasing the amount of memory in use nor the percentage of CPU load as time passes--they both remain pretty constant.


bkshepard wrote on Fri, 25 September 2009 22:34

Even if you check in Activity Monitor, it looks to me like it could have something to do with memory usage and swapping (on the hard drive). Especially with the difference between reopening shortly after and reopening long later. It looks like in between, you patch has been written in the swap file (on the hard drive). And reopening from swap and reopening from memory makes a huge difference in terms of loading time !

Well, that's just how it sounds to me... Maybe it's not the explanation but it can be a lead.

bkshepard wrote on Fri, 25 September 2009 22:34Also, once the window has been opened and closed, it opens again quite quickly--even if DSP is on--if you open it soon after closing it.  However, once time has passed again, it's back to being a slow poke!

Hi !
Even if you check in Activity Monitor, it looks to me like it could have something to do with memory usage and swapping (on the hard drive). Especially with the difference between reopening shortly after and reopening long later. It looks like in between, you patch  has been written in the swap file (on the hard drive). And reopening from swap and reopening from memory makes a huge difference in terms of loading time !

Well, that's just how it sounds to me... Maybe it's not the explanation but it can be a lead.


As an experiment, I tried leaving the application open, but DSP turned off for a long time and the subpatchers opened instantly. Then, I quit and relaunched the app, but turned DSP on and waited the same amount of time. Subpatchers took a long time to open.

Is there a way to have the window stay in memory instead of being written to the swap file?

Not sure if this helps, but I had a similar issue for a while - if I left DSP active, and my app in the background, after a short time it would take AGES to come to the foreground again. IE 10 minutes in the background = 20 minutes waiting for it to come to the front.

Oddly enough I stumbled on a fix of just not allowing my LCD objects (which were, at some point, driven by a train~ object) to draw anything. There's an object (the name escapes me at the moment) that reports a 1 or 0 depending on if it's window is in the front. I put it in my various subpatchers, linked in a way that toggled a gate to my LCD's input if the app was in the background, making it not display anything. No more weird stalling issue.

No idea if you can figure out a way to make this work for you, but if you're sending a lot of drawing commands to LCDs that might be a place to look.

Oddly enough I stumbled on a fix of just not allowing my LCD objects (which were, at some point, driven by a train~ object) to draw anything.  There's an object (the name escapes me at the moment) that reports a 1 or 0 depending on if it's window is in the front.  I put it in my various subpatchers, linked in a way that toggled a gate to my LCD's input if the app was in the background, making it not display anything.  No more weird stalling issue.

No idea if you can figure out a way to make this work for you, but if you're sending a lot of drawing commands to LCDs that might be a place to look.


bkshepard wrote on Sat, 26 September 2009 01:43

I don't think you can choose whether an app or a window stay in RAM or is saved in the swap. But what amount of RAM do you have ? Are you recording something when DSP is turned on ? Or doing anything that could require a huge quantity of memory ?

Another test could be to try your patches on another machine (with more memory) and see if it changes anything. At least you could be certain about the link (or lack of link) with the memory.

MuShoo wrote on Sat, 26 September 2009 09:54

There's an object (the name escapes me at the moment) that reports a 1 or 0 depending on if it's window is in the front.

The object is [active] and it's maybe not a bad idea to use it to activate/deactivate some functionality of your patch when windows are in background. I could save you a lot of memory.

But again, maybe memory is not the (only) issue here.

PS : btw, I discover recently that my Thunderbird and Safari and FireFox are actually jamming a big part of my memory... A good practice may be to close those app when using Max for a performance ! ;o)

[EDIT] owned for the [active] object ;o) I'm not fast enough

bkshepard wrote on Sat, 26 September 2009 01:43Hmm, that makes sense. 

MuShoo wrote on Sat, 26 September 2009 09:54There's an object (the name escapes me at the moment) that reports a 1 or 0 depending on if it's window is in the front.

[EDIT] owned for the [active] object ;o) I'm not fast enough


Hey gang, thanks for all the hints and suggestions.

The app doesn't record any audio, just processes and outputs incoming audio. I do, however, use one instance of tapin/tapout for a delay line.

I am using LCD objects, but as has been suggested, I'm already using [active] to wait to start drawing after the window has opened. It's worth a revisit, though, to make sure I haven't missed something.

I've tried the app on a number of computers with plenty of RAM and it doesn't seem to make a difference.

It also has the problem with no other apps are running--even after a fresh reboot of the computer.

Well, it turns out that the long window opening time after the app was running WAS related to LCD, but not exclusively to the drawing commands. It was also affected by loading and storing the image file into the LCD. After a bunch of experimentation, I found that if I told the LCD to wait until the window was active to load and draw the image file AND told it to unload the image when the window closed, all works well and the windows open quite quickly--even after the app has been running for several hours.

Perhaps "the Devs" could give LCD a once-over sometime soon, it seems to have some sort of odd leaky problem. Mine was related to a barrage of drawing commands piling up (I think) and yours is image-load based, it seems. Whatever it is, it looks like LCD has some trouble coping when it's in the background.

I'm pretty sure LCD was rebuilt for Max5, perhaps some little critter snuck in and is running amok.

Does this sound like a memory leak?