Thread: [Pyobjc-dev] Initial memory usage
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Arif A. <ari...@gm...> - 2009-09-21 08:39:49
|
Hi all, I've recently started developing PyObjC apps and my app memory usage shot off to 75MB. So I created a small Hello World app with just one NSWindow and the initial memory was 36MB. I'd assume this would be expected since the entire Python interpreter is running within the app it might take that much. So is it safe to assume that all PyObjC apps need a minimum of 30+M to work? Versions: Mac OS X 10.5.8 >>> print objc.__version__ 2.2b2 Thanks, Arif Amirani Blog: http://blog.tripmeter.in |
|
From: Ronald O. <ron...@ma...> - 2009-09-29 20:38:47
Attachments:
smime.p7s
|
On 21 Sep, 2009, at 10:39, Arif Amirani wrote: > Hi all, > > I've recently started developing PyObjC apps and my app memory usage > shot off to 75MB. So I created a small Hello World app with just one > NSWindow and the initial memory was 36MB. I'd assume this would be > expected since the entire Python interpreter is running within the > app it might take that much. So is it safe to assume that all PyObjC > apps need a minimum of 30+M to work? I guess so. I haven't done serious measuments of PyObjC memory usage beyond checking that PyObjC doesn't leak memory. How did you measure the memory usage? Ronald > > Versions: > Mac OS X 10.5.8 > > >>> print objc.__version__ > 2.2b2 > > Thanks, > Arif Amirani > > Blog: http://blog.tripmeter.in > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf_______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
|
From: Arif A. <ari...@gm...> - 2009-09-30 10:03:15
|
Hi Ronald, I've tried this with Activity Monitor, top and some 3rd party tool. I get a consistent usage of 30+M for the single window app. Is there a more robust way of determining app memory usage? Thanks, Arif Amirani http://blog.tripmeter.in On Wed, Sep 30, 2009 at 2:08 AM, Ronald Oussoren <ron...@ma...>wrote: > > On 21 Sep, 2009, at 10:39, Arif Amirani wrote: > > Hi all, > I've recently started developing PyObjC apps and my app memory usage shot > off to 75MB. So I created a small Hello World app with just one NSWindow and > the initial memory was 36MB. I'd assume this would be expected since the > entire Python interpreter is running within the app it might take that much. > So is it safe to assume that all PyObjC apps need a minimum of 30+M to work? > > > I guess so. I haven't done serious measuments of PyObjC memory usage beyond > checking that PyObjC doesn't leak memory. > > How did you measure the memory usage? > > Ronald > > > Versions: > Mac OS X 10.5.8 > > >>> print objc.__version__ > 2.2b2 > > Thanks, > Arif Amirani > > Blog: http://blog.tripmeter.in > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf_______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > > > |
|
From: Arif A. <ari...@gm...> - 2009-09-30 14:06:27
|
Hi all, A small update. I tried the same with a Ruby Cocoa bridge and the exact single window app started off with only 9M+ memory usage. I'll try a few more tests but otherwise this looks like a huge difference between native cocoa - ruby cocoa and pyobjc apps. Thanks, Arif http://blog.tripmeter.in On Wed, Sep 30, 2009 at 3:32 PM, Arif Amirani <ari...@gm...>wrote: > Hi Ronald, > I've tried this with Activity Monitor, top and some 3rd party tool. I get a > consistent usage of 30+M for the single window app. > > Is there a more robust way of determining app memory usage? > > Thanks, > Arif Amirani > http://blog.tripmeter.in > > > On Wed, Sep 30, 2009 at 2:08 AM, Ronald Oussoren <ron...@ma...>wrote: > >> >> On 21 Sep, 2009, at 10:39, Arif Amirani wrote: >> >> Hi all, >> I've recently started developing PyObjC apps and my app memory usage shot >> off to 75MB. So I created a small Hello World app with just one NSWindow and >> the initial memory was 36MB. I'd assume this would be expected since the >> entire Python interpreter is running within the app it might take that much. >> So is it safe to assume that all PyObjC apps need a minimum of 30+M to work? >> >> >> I guess so. I haven't done serious measuments of PyObjC memory usage >> beyond checking that PyObjC doesn't leak memory. >> >> How did you measure the memory usage? >> >> Ronald >> >> >> Versions: >> Mac OS X 10.5.8 >> >> >>> print objc.__version__ >> 2.2b2 >> >> Thanks, >> Arif Amirani >> >> Blog: http://blog.tripmeter.in >> >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf_______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> >> >> > |
|
From: Bill B. <bb...@ma...> - 2009-09-30 17:33:52
|
On Sep 30, 2009, at 6:38 AM, Arif Amirani wrote: > A small update. I tried the same with a Ruby Cocoa bridge and the > exact single window app started off with only 9M+ memory usage. I'll > try a few more tests but otherwise this looks like a huge difference > between native cocoa - ruby cocoa and pyobjc apps. Is it allocations or is it memory mapped gunk? If it is allocations, that is a problem. If it is memory mapped stuff -- shared libraries, etc -- you shouldn't care. b.bum |
|
From: Arif A. <ari...@gm...> - 2009-09-30 18:32:52
|
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. Thanks, Arif On Wed, Sep 30, 2009 at 11:03 PM, Bill Bumgarner <bb...@ma...> wrote: > > On Sep 30, 2009, at 6:38 AM, Arif Amirani wrote: > > A small update. I tried the same with a Ruby Cocoa bridge and the exact >> single window app started off with only 9M+ memory usage. I'll try a few >> more tests but otherwise this looks like a huge difference between native >> cocoa - ruby cocoa and pyobjc apps. >> > > Is it allocations or is it memory mapped gunk? > > If it is allocations, that is a problem. > > If it is memory mapped stuff -- shared libraries, etc -- you shouldn't > care. > > b.bum > > |
|
From: Ronald O. <ron...@ma...> - 2009-09-30 19:47:30
Attachments:
smime.p7s
|
On 30 Sep, 2009, at 20:32, 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. I'm looking with instruments as well, I'm using the basic TableModel example from pyobjc-framework-Cocoa to test. The bulk of memory usage is due to PyMem_Malloc, which is Python's memory allocator. Python has its own allocator build on top of malloc to get better performance (malloc()/free() are not fast enough on most platforms, and there's also a risk for memory fragmentation). The next question is: is the memory usage real, or is most of it just the memory arena's for PyMem_Malloc. To be continued, Ronald > > Thanks, > Arif > > On Wed, Sep 30, 2009 at 11:03 PM, Bill Bumgarner <bb...@ma...> wrote: > > On Sep 30, 2009, at 6:38 AM, Arif Amirani wrote: > > A small update. I tried the same with a Ruby Cocoa bridge and the > exact single window app started off with only 9M+ memory usage. I'll > try a few more tests but otherwise this looks like a huge difference > between native cocoa - ruby cocoa and pyobjc apps. > > Is it allocations or is it memory mapped gunk? > > If it is allocations, that is a problem. > > If it is memory mapped stuff -- shared libraries, etc -- you > shouldn't care. > > b.bum > > |
|
From: Bill B. <bb...@ma...> - 2009-09-30 19:59:31
|
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. b.bum |
|
From: Ronald O. <ron...@ma...> - 2009-09-30 21:08:53
Attachments:
smime.p7s
|
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 |
|
From: Bill B. <bb...@ma...> - 2009-10-01 21:34:49
|
On Oct 1, 2009, at 2:26 PM, Samantha Atkins wrote: > I am curious about this. These tables in Objective C runtime don't take a lot of space. What sort of overhead is introduced converting the information to pyobjc equivalents? On the face of it I don't see why this would take a lot of memory or be all that computationally expensive. Isn't this information needed not just for dir() but for sending any message to an objc object? So why not pay the scan cost once at class/bundle load time and then forget about it? Assuming it can be made reasonably efficient of course. I guess I should finally get around to looking in the guts of this bridge. It is somewhere on my bloated todo list. It isn't the ObjC metadata directly, but a combination of that and the bridge support XML files; all that XML is dragged in, shoved into data structures and kept around. b.bum |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X