".....your Desktop PC being that MS-Windows..." aaaaww sis man, it's all Linux :))))
I wanted to make sure I've not missed some compile trick for this sort of thing. ".....So maybe you should try to come up with a patch, to find out if the cache helps?" Yes, now that I know I've not ignored some obvious "everybody knows not to do that" trick I'll look into some form of cache.....although off the top of my head I imagine it''ll be difficult to precede every open with a cache lookup....perhaps this is something better suited for the underlying "uClibc" framework....but then who refreshes the cache. Thanks for the thoughts and idea, if I find a nice solution I'll be sure to post an update. Bruce On Thu, Mar 24, 2011 at 4:18 PM, James Y Knight <f...@fuhm.net> wrote: > On Mar 24, 2011, at 11:58 AM, bruce bushby wrote: > > My main concern was that a freshly compiled Python attempts to open 168 > non-existent files before starting. > > > > I understand that an interpreted language is probably not the best choice > for an embedded device (although it's very nice for prototyping) , Python > really should know what exists after it's just been compiled....ie before > any corrupting modules or other nonsense has been added. > > > > It appears it is hard coded to open these files regardless of any > "configure" options. > > > > On my desktop pc, when I run the most simple "Hello World" .... 78% of > the overall execution time is spent opening files....most of which don't > exist. > > > > Some form of "cache" would help the startup time on the "second go" ..... > but arguably just a "band aid" covering a deeper problem. > > The deeper problem on your Desktop PC being that MS-Windows' file system > calls are horrifically expensive for no good reason? :) > > James
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
