This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients brett.cannon, pitrou
Date 2012-02-17.19:31:55
SpamBayes Score 3.9751535e-13
Marked as misclassified No
Message-id <1329506921.3678.22.camel@localhost.localdomain>
In-reply-to <1329505043.59.0.00908460651778.issue14043@psf.upfronthosting.co.za>
Content
> Why pre-calculate everything? In the most common case any single
> module will be imported once, if at all. And once it is imported it
> will get cached in sys.modules, alleviating the need to hit the finder
> again. So from a performance standpoint wouldn't it be better not to
> do all of the pre-calculation and instead do that as needed assuming
> that sys.modules will shield the finder from having to do repetitive
> things like figuring out what loader is needed?

I figured it would avoid repetitive tests for all 10 suffixes.
That said, I have now tried the alternative: find_module() is around 50%
slower, but building the cache is 10x faster. Perhaps this is a winner.
It would depend on the situation (short or long sys.path, few or many
imports, etc.). Perhaps you can try both patches on your bootstrap repo?

>  Plus if the finder gets its cache invalidated frequently it  will
> simply be wasting its time.

Well, in real-world situations I don't think the cache will ever get
invalidated: because imports are mostly done at startup, and because
invalidating the cache means you are installing new libraries or
updating existing ones while a running program is about to import
something.

> Otherwise it's good to know three of us now have independently come up
> with fundamentally the same idea for speeding up imports. =)

Yup :)
History
Date User Action Args
2012-02-17 19:31:56pitrousetrecipients: + pitrou, brett.cannon
2012-02-17 19:31:55pitroulinkissue14043 messages
2012-02-17 19:31:55pitroucreate