Thread: [Pyobjc-dev] PyObjc speed
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: David B. <te...@bi...> - 2003-07-08 14:34:19
|
After seeing the announcement for PyObjc on the cocoa-dev list, I decided t= o=20 download and try it out. Unfortunetly, I think (hope!) I'm doing something= =20 wrong. I have a 300Mhz iBook with 284 Megs of ram. It isn't a speed demon= ,=20 but Jaguar runs fine on it. However, when using a brand-new Python/Cocoa=20 project (the template), it takes *20* seconds to startup. In comparasion P= B=20 takes about 5. If I run the program, then kill it and immediately launch i= t=20 again, it drops to 18 seconds. Either one is way too long to be usable. A= ny=20 ideas of what I should try? Some sort of pre-compile? Use MacPython rathe= r=20 than the built-in 2.2? I can appreciate that it will not be as fast as=20 ObjC/Cocoa app, but... Many thanks! =2D-=20 "Sorry about the whole 'bomb' thing" - Bruce Rollins D.A.Bishop |
|
From: David B. <te...@bi...> - 2003-07-08 14:40:46
|
[sorry, forgot to mention that I'm not signed up to the list, so please cc:= me=20 on any replies] After seeing the announcement for PyObjc on the cocoa-dev list, I decided t= o=20 download and try it out. Unfortunetly, I think (hope!) I'm doing something= =20 wrong. I have a 300Mhz iBook with 284 Megs of ram. It isn't a speed demon= ,=20 but Jaguar runs fine on it. However, when using a brand-new Python/Cocoa=20 project (the template), it takes *20* seconds to startup. In comparasion P= B=20 takes about 5. If I run the program, then kill it and immediately launch i= t=20 again, it drops to 18 seconds. Either one is way too long to be usable. A= ny=20 ideas of what I should try? Some sort of pre-compile? Use MacPython rathe= r=20 than the built-in 2.2? I can appreciate that it will not be as fast as=20 ObjC/Cocoa app, but... Many thanks! =2D-=20 "Sorry about the whole 'bomb' thing" - Bruce Rollins D.A.Bishop |
|
From: b.bum <bb...@ma...> - 2003-07-08 15:41:05
|
The problem is a result of the lack of a library with which to embed the Python 2.2. interpreter on OS X 10.2. If you build and install the framework version of Python 2.3b1 and use an embedded interpreter, the launch times drop significantly. Launching a PyObjC app will always be a bit slower because of the additional pieces that must be initialized, but not 3x slower! b.bum On Tuesday, July 8, 2003, at 10:40 AM, David Bishop wrote: > [sorry, forgot to mention that I'm not signed up to the list, so > please cc: me > on any replies] > > After seeing the announcement for PyObjc on the cocoa-dev list, I > decided to > download and try it out. Unfortunetly, I think (hope!) I'm doing > something > wrong. I have a 300Mhz iBook with 284 Megs of ram. It isn't a speed > demon, > but Jaguar runs fine on it. However, when using a brand-new > Python/Cocoa > project (the template), it takes *20* seconds to startup. In > comparasion PB > takes about 5. If I run the program, then kill it and immediately > launch it > again, it drops to 18 seconds. Either one is way too long to be > usable. Any > ideas of what I should try? Some sort of pre-compile? Use MacPython > rather > than the built-in 2.2? I can appreciate that it will not be as fast as > ObjC/Cocoa app, but... > > Many thanks! > > -- > "Sorry about the whole 'bomb' thing" - Bruce Rollins > D.A.Bishop > > > <mime-attachment> |
|
From: Ronald O. <ous...@ci...> - 2003-07-08 18:05:17
|
On Tuesday, 8 July, 2003, at 17:40, b.bum wrote: > The problem is a result of the lack of a library with which to embed > the Python 2.2. interpreter on OS X 10.2. If you build and install > the framework version of Python 2.3b1 and use an embedded interpreter, > the launch times drop significantly. > > Launching a PyObjC app will always be a bit slower because of the > additional pieces that must be initialized, but not 3x slower! One of the problems we're having, and why an embedded interpreter is much faster, is that the Foundation and AppKit frameworks get dynamicly loaded. This means preloading doesn't work, which in turn means much slower loading. If anyone knows how to make sure preloading works with Python modules please tell us, that would be really helpfull. Jack has experimented with a /usr/local/bin/python that has been linked with AppKit and that caused much faster loading of PyObjC. This won't make it into the 2.3 release because it is unclear what the side effects of linking with AppKit are. We want to be 100% sure that /usr/local/bin/python runs without access to the WindowServer. Ronald |
|
From: Bob I. <bo...@re...> - 2003-07-08 18:29:12
|
On Tuesday, Jul 8, 2003, at 14:04 America/New_York, Ronald Oussoren wrote: > > On Tuesday, 8 July, 2003, at 17:40, b.bum wrote: > >> The problem is a result of the lack of a library with which to embed >> the Python 2.2. interpreter on OS X 10.2. If you build and install >> the framework version of Python 2.3b1 and use an embedded >> interpreter, the launch times drop significantly. >> >> Launching a PyObjC app will always be a bit slower because of the >> additional pieces that must be initialized, but not 3x slower! > > One of the problems we're having, and why an embedded interpreter is > much faster, is that the Foundation and AppKit frameworks get > dynamicly loaded. This means preloading doesn't work, which in turn > means much slower loading. If anyone knows how to make sure preloading > works with Python modules please tell us, that would be really > helpfull. > > Jack has experimented with a /usr/local/bin/python that has been > linked with AppKit and that caused much faster loading of PyObjC. This > won't make it into the 2.3 release because it is unclear what the side > effects of linking with AppKit are. We want to be 100% sure that > /usr/local/bin/python runs without access to the WindowServer. It's a pretty safe bet that unless Apple changes WindowServer and/or LaunchServices significantly, no binary will ever have legitimate access to WindowServer *unless* argv[0] points to the inside of a valid bundle (either though normal exection or execve).. nomatter what you link to and when. Even still, regardless of how the binary was executed, it is possible to hijack WindowServer support at runtime (assuming the user would otherwise have access to WindowServer) if you know which magic private api function to call. -bob |
|
From: Ronald O. <ous...@ci...> - 2003-07-08 18:49:44
|
On Tuesday, 8 July, 2003, at 20:29, Bob Ippolito wrote: > On Tuesday, Jul 8, 2003, at 14:04 America/New_York, Ronald Oussoren > wrote: > >> >> On Tuesday, 8 July, 2003, at 17:40, b.bum wrote: >> >>> The problem is a result of the lack of a library with which to embed >>> the Python 2.2. interpreter on OS X 10.2. If you build and >>> install the framework version of Python 2.3b1 and use an embedded >>> interpreter, the launch times drop significantly. >>> >>> Launching a PyObjC app will always be a bit slower because of the >>> additional pieces that must be initialized, but not 3x slower! >> >> One of the problems we're having, and why an embedded interpreter is >> much faster, is that the Foundation and AppKit frameworks get >> dynamicly loaded. This means preloading doesn't work, which in turn >> means much slower loading. If anyone knows how to make sure >> preloading works with Python modules please tell us, that would be >> really helpfull. >> >> Jack has experimented with a /usr/local/bin/python that has been >> linked with AppKit and that caused much faster loading of PyObjC. >> This won't make it into the 2.3 release because it is unclear what >> the side effects of linking with AppKit are. We want to be 100% sure >> that /usr/local/bin/python runs without access to the WindowServer. > > It's a pretty safe bet that unless Apple changes WindowServer and/or > LaunchServices significantly, no binary will ever have legitimate > access to WindowServer *unless* argv[0] points to the inside of a > valid bundle (either though normal exection or execve).. nomatter what > you link to and when. That's why we have to be carefull. If there's any initialization code in AppKit that requires access to the WindowServer we'd be hosed if the python interpreter were linked with AppKit. Ronald |
|
From: Just v. R. <ju...@le...> - 2003-07-08 18:43:30
|
Ronald Oussoren wrote: > One of the problems we're having, and why an embedded interpreter is > much faster, is that the Foundation and AppKit frameworks get > dynamicly loaded. This means preloading doesn't work, which in turn > means much slower loading. If anyone knows how to make sure > preloading works with Python modules please tell us, that would be > really helpfull. > > Jack has experimented with a /usr/local/bin/python that has been > linked with AppKit and that caused much faster loading of PyObjC. > This won't make it into the 2.3 release because it is unclear what > the side effects of linking with AppKit are. We want to be 100% sure > that > /usr/local/bin/python runs without access to the WindowServer. (thinking out loud) I think that for 2.3 we should make a special (Objective-)C main program that takes over the bootstrap stuff, is linked against Cocoa and Python.framework, and does not do the os.execve() trick. It can look up additional info in the Info.plist file (like, what Python main program to execute). I think it wouldn't be all that unlike Bill's bin-python-main.m. It won't have to be compiled every time, we can ship it with a binary distro so we're still able to build apps without the dev tools. Just |
|
From: Ronald O. <ous...@ci...> - 2003-07-08 18:55:45
|
On Tuesday, 8 July, 2003, at 20:42, Just van Rossum wrote: > (thinking out loud) I think that for 2.3 we should make a special > (Objective-)C main program that takes over the bootstrap stuff, is > linked against Cocoa and Python.framework, and does not do the > os.execve() trick. It can look up additional info in the Info.plist > file > (like, what Python main program to execute). I think it wouldn't be all > that unlike Bill's bin-python-main.m. It won't have to be compiled > every > time, we can ship it with a binary distro so we're still able to build > apps without the dev tools. +1 from me. If linking with Cocoa and Carbon is not too expensive we might even do that, and try to sell the idea to Jack as a genericly usefull thing for MacPython :-) Ronald |
|
From: Just v. R. <ju...@le...> - 2003-07-08 19:13:39
|
Ronald Oussoren wrote: > +1 from me. > > If linking with Cocoa and Carbon is not too expensive we might even > do that, and try to sell the idea to Jack as a genericly usefull > thing for MacPython :-) Yeah, it could almost be the generic main program. But ideally it should look in the Info.plist file which Python program to execute. That's an option for Python.app (as embedded inside Python.framework). Just |
|
From: b.bum <bb...@ma...> - 2003-07-08 19:34:27
Attachments:
main-embedded-interpreter.m
|
On Tuesday, July 8, 2003, at 2:42 PM, Just van Rossum wrote: > (thinking out loud) I think that for 2.3 we should make a special > (Objective-)C main program that takes over the bootstrap stuff, is > linked against Cocoa and Python.framework, and does not do the > os.execve() trick. It can look up additional info in the Info.plist > file > (like, what Python main program to execute). I think it wouldn't be all > that unlike Bill's bin-python-main.m. It won't have to be compiled > every > time, we can ship it with a binary distro so we're still able to build > apps without the dev tools. Just look in the attic... ;-) Web Services Tool originally used an embedded interpreter. And it does again -- the project templates should be updated, at some point. You can actually have a single template covering both cases, but it make project administration somewhat of a bear. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X