Re: [Pyobjc-dev] NSApplicationMain idiom: wish to standardize

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

On Friday, Mar 21, 2003, at 18:02 Europe/Amsterdam, Just van Rossum 
wrote:
>
>> Speaking of NSApplicationMain... Does anyone care to offer on opinion
>> on the enormous amount of time between the call to NSApplicationMain
>> and the call to awakeFromNib in a simple application? That period of
>> time takes about 4 seconds of the 5 seconds my application needs to
>> start up
>
> I'm also still seeing long startup times, about 8-10 seconds. I'll
> measure later how much of that is spent between NSApplicationMain() and
> the first awakeFromNib call.

Part of the time is in bootstrapping Python, not much we can do about 
that (and not part of the 5 seconds I mentioned earlier).

>
>> (using a savagely butchered version of PyObjC, 'import
>> AppKit' would use another 2 seconds if I hadn't build a mini module
>> that exports all definitions I need from AppKit and Foundation).
>
> Does this mean we should revisit the idea of replacing the Cocoa 
> modules
> with "lazy" module-like objects? If *you* are butchering up PyObjC that
> should be a sign...

As a datapoint (PB 667Mhz) I've done some crude experiments using the 
TableModel example (Python 2.3):

* Plain example starts in 6 bounces

* Objective-C version of same starts in 2 bounces

* Simplified AppKit/Foundation starts in 4 bounces

I've attached the source code for the modified versions. Building these 
is not too hard: Call buildapp.py to create the plain version. For the 
Objective-C version compile tm.m and use that to replace 
Contents/MacOS/TableModel. For the simplified version copy 
TableModel.py to Contents/Resources and then copy _AppKit*, 
NibClassBuilder.py* and _Foundation* from the site-packages directory 
to Contents/Resources.

Some further investigation shows lots (about 8000) of calls to 
get_class_info in objc-class.m between the call to NSApplicationMain 
and the call to awakeFromNib. Removing these calls using the new 
PyHeapTypeObject to store the additional information in the class proxy 
instead of a seperate datastructure doesn't reduce the startup time for 
me. It would have made live much easier if this had been available in 
2.2 :-). I'll probably add this change to CVS if I can do so without 
negative effects on the source code.

Ronald

P.S. bundlebuilder.py from the current Python CVS doesn't work for me, 
I get #!python2.3 at the start of the bootstrap script. That's probably 
because 'which python' is  '/usr/local/bin/python' and that is a 
symlink to 'python2.3' in the same directory.  This fragment of code 
doesn't work correctly with that:
   hashbang = sys.executable
   while os.path.islink(hashbang):
      hashbang = os.readlink(hashbang)

The second time through the loop hashbang is 'python2.3', which doesn't 
exist. The assignment should probably be something like 
'os.path.join(os.dirname(hashbang), os.readlink(hashbang))'