Re: [Pyobjc-dev] PyObjc speed

[Ronald O. <ous...@ci...>]

On Tuesday, 8 July, 2003, at 20:29, Bob Ippolito wrote:

> On Tuesday, Jul 8, 2003, at 14:04 America/New_York, Ronald Oussoren 
> wrote:
>
>>
>> On Tuesday, 8 July, 2003, at 17:40, b.bum wrote:
>>
>>> The problem is a result of the lack of a library with which to embed 
>>> the Python 2.2. interpreter on OS X 10.2.    If you build and 
>>> install the framework version of Python 2.3b1 and use an embedded 
>>> interpreter, the launch times drop significantly.
>>>
>>> Launching a PyObjC app will always be a bit slower because of the 
>>> additional pieces that must be initialized, but not 3x slower!
>>
>> One of the problems we're having, and why an embedded interpreter is 
>> much faster, is that the Foundation and AppKit frameworks get 
>> dynamicly loaded. This means preloading doesn't work, which in turn 
>> means much slower loading. If anyone knows how to make sure 
>> preloading works with Python modules please tell us, that would be 
>> really helpfull.
>>
>> Jack has experimented with a /usr/local/bin/python that has been 
>> linked with AppKit and that caused much faster loading of PyObjC. 
>> This won't make it into the 2.3 release because it is unclear what 
>> the side effects of linking with AppKit are. We want to be 100% sure 
>> that /usr/local/bin/python runs without access to the WindowServer.
>
> It's a pretty safe bet that unless Apple changes WindowServer and/or 
> LaunchServices significantly, no binary will ever have legitimate 
> access to WindowServer *unless* argv[0] points to the inside of a 
> valid bundle (either though normal exection or execve).. nomatter what 
> you link to and when.

That's why we have to be carefull. If there's any initialization code 
in AppKit that requires access to the WindowServer we'd be hosed if the 
python interpreter were linked with AppKit.

Ronald