On Mon, Feb 21, 2011 at 8:26 PM, Eviatar <eviatarb...@gmail.com> wrote: > Importing in a loop is definitely not a good idea.
Unless the loop is rarely executed... > I found this great guide about Python performance, including > information about importing, lazy imports, and other issues: > http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Import_Statement_Overhead The primary cost of imports is the initial import, which involves disk access and execution of code (possibly importing other modules). If a module is loaded in 5 different places, cutting out the import in only 4 of them is not much of a savings. (Well, it could be in code clarity.) Even if a module takes 1ms to load, loading 1000 of them adds up, so think before importing modules that get pulled into sage.all. In terms of where or what to import, here's my off-the-cuff recommendation for Sage. 1. Import from the lowest level .all file you can. For example, to import something from sage.rings.polynomial.Y into sage.rings.X, I'd import it from sage.rings.polynomial.all, but from sage.foo.X, I'd import it from sage.rings.all. This helps keep the dependencies clean and easy to follow, as well as being the most future proof. Often I try to avoid imports at all, e.g. use object methods like foo.sin() rather than sin(foo) or QQ['x'] rather than PolynomailRing(QQ, 'x'). 2. In terms of "import X; use X.foo" vs. "from X import foo," the latter is faster, as it does not have to do a module lookup every time. This can be especially true from Cython. If I use "sage.rings.all.foo" then it has to lookup sage, lookup rings on that, lookup all on that, and lookup foo on that. However, for infrequently called functions (especially if it's not obvious from the symbol name alone what it means), the full import path can lead to more legible code. 3. If something is only going to be used once, or is expensive, it may well be worth hiding that import in a function. 4. http://combinat.sagemath.org/doc/reference/sage/misc/lazy_import.html > Maybe it should be (at least partly) added to the Developer's Guide. I > might do it when I have time. A link would probably be sufficient, rather than trying to duplicate content. Of course, it would be a shame not to look at Cython if performance becomes an issue, which is likely to have a much better impact than some of these tips (though they're not bad). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
