Re: [Pyobjc-dev] Autopsy of a ktrace

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

On Monday, Jan 20, 2003, at 12:00 Europe/Amsterdam, Jack Jansen wrote:

>
> On Monday, Jan 20, 2003, at 07:41 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>>> Is this with a static Python or a framework python? I still haven't 
>>> gotten around at looking at prebinding, so I don't think any is 
>>> done. Also, it may be possible to prebind extension modules (haven't 
>>> checked) which may also make a difference. If this is all possible 
>>> it should be fairly simple: one prebinding magic incantation in the 
>>> main Python Makefile and explaining distutils how to prebind dynamic 
>>> modules for the Python that was used to run the distutils.
>> Framework python 2.3, last CVS update was yesterday.
>
> I've just added -prebind options to the building of Python. Framework 
> build startup has gone from 180ms to 70ms, non-framework build startup 
> from 100ms to 70ms. (on my 450Mhz G4). The fix has been checked in.
I've compiled my 2.3 framework install with 'OPT="-O3 -mcpu=604 
-faltivec -prebind"'. This causes a 10% speedup of the microbenchmark 
for PyObjC that I'm working on. The downside is that the binaries only 
work on G4s.

>
> I tried enabling -prebind for the extension modules too, but the 
> linker complains that -bundle and -prebind don't go together or 
> something to that effect. Does anyone know whether there is a way 
> around this?
Doesn't -prebind perform at linktime the fixup that the dynamic loader 
normally performs at runtime? If so I'm not surprised that this doesn't 
work with bundles: The linker then doesn't have enough information. 
Building as a dylib and linking with the python framework might help 
(just guessing, this probably won't work at all).

Ronald