[Pyobjc-dev] Re: PyObjC Bridge performance
Brought to you by:
ronaldoussoren
From: Bill B. <bb...@co...> - 2002-10-23 16:26:32
|
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 |