Re: [Pyobjc-dev] Initial memory usage

[Ronald O. <ron...@ma...>]

On 30 Sep, 2009, at 21:58, Bill Bumgarner wrote:

>
> On Sep 30, 2009, at 11:32 AM, Arif Amirani wrote:
>
>> Thanks for the info Bill. How do I figure out if the memory usage  
>> is high due to allocations or mm stuff? I tried instruments but  
>> couldn't make out what I was seeing.
>
> vmmap will typically do the trick.

Most of the memory is in allocations, and the difference with  
rubycocoa seems to be due to parsing of bridgesupport files.

The "Live Bytes" column value for "All Allocations" using the "Object  
Allocator" instrument shrinks from about 24 MByte to about 12 MByte  
when I remove parsing of the bridgesupport files from a test program.  
This means that there is either a memory leak in parsing bridgesupport  
files, or PyObjC's representation of the parsed bridgesupport  
datafiles is too inefficient.   The leaks instrument points to the  
latter explaination, there are no serious leaks accoring to that  
instrument.

Our representation of the parsed brigesupport files uses fairly  
regular Python datastructures, it is likely that we can improve on that.

I'm adding this to my todo-list for a future release, the  
unnecessarily hight initial memory usage is annoying but not something  
that is trivial to fix which makes it unlikely that I'll be able to  
fix it before the next non-beta release. I really need to get PyObjC  
2.2 final out soonish.

I've also checked in a quick-win: Intern all strings loaded from the  
XML files. That doesn't help a lot, but every bit helps.

Another reason for high memory usage is that we scan the entire method  
table for a class when it is touched for the first time (basically, a  
method is called from Python). That used to be necessary to allow  
introspection using dir(), but that comes at a cost. Recent versions  
of Python have a hook for dir() that should allow for introspection  
without always scanning the entire class. This should give us a  
performance boost as well.

Ronald