thanks for your entry.

Just a quick reply to clear this up, I'll reply all other posts later.

First of all you need to differentiate between virtual memory and 
physical memory. Virtual memory will always be >= 200 MB for pretty 
much any OS X application: a lot of frameworks need to be linked in.

As for physical memory: this should be around 55 MB normally. It will 
need a few megs more or less depending on which windows are open and 
when Quartz decides to flush some cached objects.

If you have turned on the blurred fade in/out, Core Image / QC kicks 
into play. I have seen that it requires a lot of memory, but it 
eventually is being freed automatically. I definately know there is 
no bug or leak in RB in that part, because I've double and triple- 
checked the respective code with a number of memory-centric debugging 
tools when I saw it allocate more and more memory on fade in/out with 
the CI/QC effects turned on.That said I have seen CI/QC freeing its 
memory, but I don't know at which pattern or event this is happening. 
I do know, though, that this phenomen is owed to OS X internals and 
usually one would assume they do things the right way (tm).

If you are worried about this behaviour of OS X, just turn off the CI/ 
QC fade in/out effect and RB will stay at its low memory footprint 
since CI/QC don't get involved at all in that case.

Hope that helps.

Best regards, 
Felix 

also im working with the default settings.... No core image enabled!

Im a developer myself, and this looks pretty much as a memory leak.... The applicatino starts using around 26 mb, and after a few hours of use, it grows to big numbers.... Have you tried running it under malloc debug? it's a very handy tool for finding leaks... good luck! Im sure it's something very stupid....

I totally understand this kind of problems at early stages (as those are preview releases)..... It was more like a beta-tester suggestion...

I bought your software a few weeks ago (when i got my macbook pro), it's so useful! :)

best, oriol 

thanks. I've of course looked into it with MallocDebug, ObjectAlloc 
and friends. I have been looking for the wrong kind of object though: 
I had looked for Core Graphics objects that are used to cache the 
graphics rather than for the objects that manage the menu items. And 
although their release/retain/autorelease calls are balanced, it 
seems that - for whatever reason - Cocoa decides to not flush the 
autorelease pool too often, only sometimes or not at all. Adding 
another NSAutoreleasePool on top and around the main entry point for 
event handling in RB fixed the problem.

So, this issue will be fixed in preview 6.

Cheers, 
Felix 

oriol