Re: [Pyobjc-dev] PyObjc speed

[Bob I. <bo...@re...>]

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.

Even still, regardless of how the binary was executed, it is possible 
to hijack WindowServer support at runtime (assuming the user would 
otherwise have access to WindowServer) if you know which magic private 
api function to call.

-bob