[Pyobjc-dev] Re: PyObjC Bridge performance

[Bill B. <bb...@co...>]

On Wednesday, October 23, 2002, at 12:00 PM, 
pyt...@py... wrote:
> First off, the PyObjC bridge clean up work that was done by bbum and
> Ronald is truly truly welcome. I've been eyeing the pyobjc SF project
> wishing it was up to date for 6 months and wishing I knew more about
> the guts of ObjC to get into it. Its cleanup release was just about as
> timely as it could be.

Thank you.  We are currently integrating a set of unit tests that 
validate the bridge and, from that, fixing any major/glaring bugs in 
preparation for pushing out a 0.7.1 release.  Once that is out the 
door, we are looking to clean up everything to move towards a 1.0alpha 
stage.

I have been using the bridge for a while now to build a production 
quality Cocoa application that provides a GUI for a relatively complex 
web services enabled application (www.codefab.com has more 
information).  It works really well, though there are some issues that 
need to be ironed out.  At this point, I can confidently say that both 
my productive and the quality of the product have been improved by the 
introduction of PyObjC into the mix.

> Its been said before (even on this list) but bringing python to cocoa
> is a great idea if only to get more developers like me who look at objc
> syntax and think of chinese algebra. Apple would do well to pick this
> up and make it part of standard OSX.

Please file an enhancement request via bugreport.apple.com asking Apple 
to integrate PyObjC into the release of Python included with OS X.   
Mention that a Project Builder Template exists and enables first class 
Cocoa development in Python and feel free to give them my email address.

The more requests they receive, the more likely it is to happen.    I'm 
quite willing to lose some sleep making sure it happens correctly, if 
Apple decides to "go there".

> .... notes on performance realities deleted ....

> So here is my question to those of you with more bridge experience:
>
> Can the performance penalty (if one exists) be quantified
> order-of-magnitude for those of us that are curious? Perhaps even by
> category, i.e, startup time, memory management, event handling, etc.
> This could also help those of us looking to get involved in identifying
> where to dig into ObjC/Cocoa/pyobjc...

First, the launch times of PyObjC based applications is currently very 
slow because Apple does not ship a complete Python development kit with 
10.2.  Namely, the Python supplied by Apple is missing a library and 
dylib that can be used to embed the Python interpreter into an 
application.   As such, both the Foundation and the AppKit frameworks 
(and all other frameworks that come along with them) have to be 
dynamically loaded via NSBundle's API.   This causes a huge performance 
hit when starting up an application.

In using the Fink build of Python, I did some experiments where I 
embedded the Python interpreter into the application and did not 
"bootstrap" out to the /usr/bin/python interpreter.   Launch times were 
significantly faster, but still not what they should be.

As it stands, the pyobjc module behaves suboptimally when imported into 
Python in that it ends up traversing the entire Obj-C runtime as it 
binds itself into the interpreter.   There is a lot of opportunity for 
optimization within this, but it isn't going to happen before 1.0.

I haven't quantified the cost of messaging between the two environments 
against, say, a regular Python->Python or ObjC->ObjC method invocation. 
   In general, the [potential, but maybe not as currently implemented] 
cost of crossing the bridge under PyObjC is significantly less than the 
cost of crossing the bridge under the Java bridge.

In particular, Python and Objective-C are both dynamic and light weight 
in nature.   As such, it is fairly straightforward to bridge objects 
between the two.  For example, Ronald created a subclass of 
NSMutableDictionary that wraps around a PyDict object-- a python 
dictionary-- such that a dict passed across to the Obj-C side of the 
bridge doesn't have to be converted to the native ObjC collection class 
(for the Java bridge, the developer frequently ends up having to do 
these kinds of conversions because there is no way to do this kind of 
bridging).

In general, performance of a Cocoa application is more a matter of 
appropriately gluing the objects together and less about how fast you 
can implement a particular algorithm.    As such and regardless of 
language chosen, a lot of performance gains can typically be had by, 
say, implementing a better updating/invalidation alogrithm or improving 
data caching.

One of the key advantages of PyObjC is the ability to easily port a 
performance critical piece of code from Python to ObjC.   Do your 
prototyping and development in Python.... if something proves to be a 
performance bottleneck, see if you can't optimize the architecture to 
improve the situation (this goes much faster with Python than ObjC).... 
once the architecture is fairly optimal, port to ObjC if you need more 
performance.

> Thanks. Again, getting PyObjc fixed up for 10.2 has been like an early
> Christmas present this year.

Glad you like it!

> Antonio

b.bum