Memory leak?
It seems like sprintf and combine(possibly other objects) indexes every new message it receives resulting in ever increasing memory usage.IS there a way to clean that index? Did I miss something?
Tested on windows xp with max 5.0.6
Hugobox wrote on Mon, 13 April 2009 12:52It seems like sprintf and combine(possibly other objects) indexes every new message it receives resulting in ever increasing memory usage.IS there a way to clean that index? Did I miss something?
Tested on windows xp with max 5.0.6
That's how they work. You could close and restart Max to clean the index. Sorry. C, garbage collection, symbol table, bleah.
Try to find a way to not use those objects so heavily.
mz
Actually this is more a feature than a bug. For various reasons (efficiency is one of them), all the symbols are cached. They never get freed, unless you quit Max of course. That's why it's usually not recommended to generate tons of uniques symbols.
Cheers,
Emmanuel Jourdan wrote on Tue, 14 April 2009 02:02Actually this is more a feature than a bug. For various reasons (efficiency is one of them), all the symbols are cached. They never get freed, unless you quit Max of course. That's why it's usually not recommended to generate tons of uniques symbols.
Cheers,
heh, and what would you recommend him as an replacement for [sprintf] ?
(if 3 mb of fragmented memory can be a problem in a situation is another question)
Jitter Matrices, JS, Java or C? Note that it has been a feature of Max since the early beginning and that with the RAM size increase it highly unlikely that it will cause problems.
hi,
what about OSC ?
if i have this kinf of messages incoming from the network :
/sensor3 0.345
or if i generate messages with [sprintf /my/destination %s] where %s is my value.
does it mean 1 message per value stored in ram ?
cheers
g
Guillaume Evrard wrote on Mon, 20 April 2009 17:15
/sensor3 0.345
ideally it would be better if you could get something like that:
/sensor 3 0.345
with the index separated from the symbol.
Quote:
or if i generate messages with [sprintf /my/destination %s] where %s is my value.
does it mean 1 message per value stored in ram ?
not in that case, as you don't have the symout argument, the %s should be converted back to a float, although I would rather use %f instead. Furthermore, I try not to use sprintf when it's not required. In your example a simple prepend would do the job.
Finally I'd like to emphasize the fact that in common usage, the fact that symbols are not freed until you restart Max is really not an issue. Remember that symbols are uniques, so your /my/destination will only be created once for instance.
thanks emmanuel,
messages caching is now more clear for me.
g
Guillaume Evrard wrote on Mon, 20 April 2009 08:15hi,
what about OSC ?
if i have this kinf of messages incoming from the network :
/sensor3 0.345
or if i generate messages with [sprintf /my/destination %s] where %s is my value.
does it mean 1 message per value stored in ram ?
cheers
g
I think the javascript OSC-unroute* is ok with it's symbol usage. That is, each address is a new symbol, but new values or arguments to that address don't generate new symbols.
There's also a "cheap" mode, which will generate fewer symbols. It's not "real" OSC, but it might work.
mz
Ok!
I've modified my use of sprintf to the minimum. But after playing a bit with my patch I found the following:
Right after my patch is fully loaded, I check Max's memory usage: 125,000K. Minimize my patch: memory usage goes way down to 3,000K. Then Maximize the patch: 12,000K. That's 10 times less what it was using. What gets freed when minimizing? Is there a way to minimize and then maximize the patch on startup?
Thanks!
This topic resurection has nothing to do with sprintf, but probably related to max message caching. I have a patch that uses only native max objects that converts jitter matrices into lists. Problem is memory usage is going up 0.5 meg per second. I've noticed that minimizing and restoring the patch frees a lot of memory (around 90%). So a dirty solution is to minimize and restore the max window once in a while, but I'd like to understand what is freed when minimizing and is there a way to free it without minimizing?
Thanks