Re: [Pyobjc-dev] Bridge Support Performances

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

On 26 Jan, 2010, at 14:40, Virgil Dupras wrote:

> On Wed, Jan 20, 2010 at 10:55 PM, Ronald Oussoren
> <ron...@ma...> wrote:
>> 
>> On 20 Jan, 2010, at 22:52, Virgil Dupras wrote:
>> 
>>> On Wed, Jan 20, 2010 at 10:50 PM, Leonardo Santagada
>>> <san...@gm...> wrote:
>>>> 
>>>> On Jan 20, 2010, at 7:45 PM, Ronald Oussoren wrote:
>>>> 
>>>>> On 20 Jan, 2010, at 12:30, Virgil Dupras wrote:
>>>>> 
>>>>>> Hi there,
>>>>>> 
>>>>>> I recently started to use PyObjC 2.2 (after having use 1.4 for a long
>>>>>> time), mainly for 64-bit support, and the biggest problem I have with
>>>>>> it is bridge support's memory usage. One of my applications which used
>>>>>> to use 22mb of memory on launch when built with pyobjc 1.4 used 48mb
>>>>>> when built with pyobjc 2.2.
>>>>> 
>>>>> Ouch.
>>>> 
>>>> Can it be that a good part of this doubling in size is just from pointers going from 32 to 64bits?
>>>> 
>>>> --
>>>> Leonardo Santagada
>>>> santagada at gmail.com
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> No, 48mb is in 32bit mode. When in 64-bit mode, it's 95mb
>> 
>> This definitly needs time with a measurement tool then, I wouldn't have expected that the amount of memory used would actually double in 64-bit mode.
>> 
>> Ronald
>> 
>> 
> 
> I just wanted to let you know, Ronald (and everyone else), that I
> began working on an experimental fork of PyObjC to reduce its initial
> memory usage. I have just committed a change that reduces initial
> memory usage for "import AppKit" in 64-bit from 58mb to 31 mb without
> making a single test unit fail. This fork is at
> http://hg.hardcoded.net/pyobjc . I have also documented by experiments
> in the project's wiki. I'd greatly appreciate your feedbacks on this.

Interesting.  At first glance your change indicates that the xml files contain loads of junk that should be removed. That is, the nodes that shouldn't be included according to "methodNodeHasSpecialArgs" probably shouldn't be in the xml file in the first place.  

That means the bridgesupport generator is even more broken than I already knew. That is not a complete surprise though, the pyobjc generator is a crude hack that should be replaced by a cleaner design. If I had the time I'd rearchitect the metadata generator into two parts: (1) a clang-based tool that just prints all definitions in header files into some convenient format (json or xml) and (2) a tool that can merge the output of the first tool for various architectures and an exceptions file.   For added bonus points there should be a gui tool that makes editing the exceptions easier.

BTW. I noticed you also intend to work on documentation: I'm (slowly) converting documentation into Sphynx format in the pyobjc-core trunk. I wouldn't mind adding internal C documentation to that as well.

Ronald

> --
> Virgil Dupras
> Hardcoded Software
> http://www.hardcoded.net
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev