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 brett.cannon
Recipients brett.cannon, eric.snow, neologix, pitrou
Date 2012-04-21.04:50:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
OK, so a cursory look at importlib suggests that the possible costs of those stat calls (by looking at what has to examine the filesystem) are:

* os.listdir() for caching
* os.path.isdir() for directories if they are a package
* os.path.isfile() for
* os.path.isfile() for a module (and all the possible extensions)
* os.stat() for details of bytecode
* reading any bytecode
* reading the source
* writing the bytecode

So looking at that initial block of stat calls, I am willing to bet that Lib is getting the stat call by the os.path.isdir() check in the finder, the 2 Lib/ checks are from the finder checking the file exists and then stat'ing in the loader for bytecode verification, and then finally the opening of the bytecode to read it and discover it's usable.

As for the multiple stat calls on directories, that's validating the cache isn't out-of-date which I don't see how that can be avoided short of hitting the system clock to see if some amount of time has passed.

As for the multiple stat calls between the finder and the loader, I don't see any way to cut that down without coming up with a find + load API which makes the call immediately or some way to pass in stat details, else you have race conditions on the status of the file before you check if the bytecode is stale. If the stat calls on the directories for cache validation is too frequent, then issue #14067 is probably your best bet.
Date User Action Args
2012-04-21 04:50:28brett.cannonsetrecipients: + brett.cannon, pitrou, neologix, eric.snow
2012-04-21 04:50:27brett.cannonsetmessageid: <>
2012-04-21 04:50:27brett.cannonlinkissue14604 messages
2012-04-21 04:50:27brett.cannoncreate