2009/5/5 P.J. Eby <p...@telecommunity.com>: > At 06:57 PM 5/4/2009 -0500, Ian Bicking wrote: >> >> * I'm uncomfortable with the way entry points are scanned. I haven't >> looked close enough to back it up with numbers, but I think there's a >> noticeable performance degradation when the number of installed packages >> becomes large. (Given the algorithm this would be expected.) > > It's linear in the number of entry_points.txt files, yes, but in most apps > it should occur at most once, since pkg_resources has a single WorkingSet > object holding Distribution objects which cache their entry point data upon > first access. > > There are all sorts of ways you could make different tradeoffs, but this > particular set of tradeoffs was optimized for a single-application > environment, rather than a massive global shared site-packages where there > are plugins for every application on the system. It was also optimized for > the zipimport case, because you can tell whether a project has entry points > from its cached zip directory, that's needed at startup anyhow. >
Would it make sense then to maintain an global index of all entry points, that would be updated upon installation / uninstallation (if it's added like we wrote in PEP 376) rather than scanning the paths everytime ? we could have one index file per site-package-like directory, and discover index files rather than all directories / zip files. Extra paths added in sys.path would be omited but I don't see it as a problem -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
