Re: [Pyobjc-dev] Startup time woes

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

On Friday, Jan 17, 2003, at 23:02 Europe/Amsterdam, Just van Rossum 
wrote:

> [this started as a private conversation, I guess it makes more sense on
> the list now]
>
> Bill Bumgarner wrote:
>
>> Yes -- I'd like to know why it is so bloody slow, as well.

I guess this is  because we do too much work...

>>
>> I'm going to have to run it through the profiler sometime soon and see
>> what the deal is.
>>
>> Part of the problem is certainly the bridging of *all* classes.
>> I.e. 'from AppKit import *' has to do a lot of work to make all of
>> the classes available in the Python module, but I don't think that
>> explains *all* of the slowdown.
That shouldn't be too much of a problem. In the CVS version we lazily 
build
the class __dict__, before that we did have a real problem 
(unnecessarily
building class dictionaries for classes that don't need one).

>
> Hm, I was also thinking it would have to be something different. I 
> added
> some print statements to a simple app (the pyDotView example that was
> posted recently):

Could you elaborate a little:
* What's the version of PyObjC
* The type and speed of the CPU
* Do these print-statements print times from the start of the program,
   or the time from the previous print statement?

>
>     (first run)
>     after importing objc: 0.330672979355
>     after importing Foundation: 0.997979998589
>     after importing AppKit: 3.49985897541
>     after importing MyAppDelegate: 3.72730898857
>     (starting the event loop)
>     initializing DotView: 11.8096979856
>
>     (second run)
>     after importing objc: 0.102402925491
>     after importing Foundation: 0.417948961258
>     after importing AppKit: 1.14622688293
>     after importing MyAppDelegate: 1.30699288845
>     (starting the event loop)
>     initializing DotView: 8.59571492672
>
> Times in seconds from the top of __main__. The "initializing" line is
> from the DotView.initWithFrame_() method. Much time is spent between
> starting the event loop and setting up the window. Weird.
>
> This was with 2.2, however, with 2.3 I get a different number at the
> end:
>
>     (first run)
>     after importing objc: 0.306917071342
>     after importing Foundation: 0.843237996101
>     after importing AppKit: 1.79104101658
>     after importing MyAppDelegate: 1.98914909363
>     (starting the event loop)
>     initializing DotView: 3.40978002548
>
>     (second run)
>     after importing objc: 0.118615984917
>     after importing Foundation: 0.377791047096
>     after importing AppKit: 1.09300804138
>     after importing MyAppDelegate: 1.22211098671
>     (starting the event loop)
>     initializing DotView: 2.63563001156
>
> Still very slow for a trivial app, but quite a bit better. But why?

Good question. Does anyone know how to do profiling on a python 
extention? If all else failes I'll hack the build procedure of Python 
and build a python that has PyObjC as a builtin extension.

I've written a simple benchmark for method dispatching and this shows 
that that is also sluggish. I've done my testing with python 2.3 and 
haven't yet checked if 2.2 is worse. I also see inconsistent results 
from various runs of my testscript: on some runs the difference between 
'normal' python dispatching and dispatching to Objective-C is twice as 
large as on other runs.

Ronald