#14187: Check that lazy imports are not resolved during startup
--------------------------------+-------------------------------------------
Reporter: vbraun | Owner: tbd
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.8
Component: performance | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Nicolas M. Thiéry
Authors: Volker Braun | Merged in:
Dependencies: #12543 | Stopgaps:
--------------------------------+-------------------------------------------
Comment (by nbruin):
Performance information? In particular, it would be interesting to see:
{{{
sage: lazy_import("lazily_imported_module","A",_as="A1")
sage: lazy_import("lazily_imported_module","A",_as="A2")
sage: %time A1
sage: %time A2
}}}
It's the second lazy import resolution that's interesting: The module is
already imported so in principle it's cheap, but we trigger a GC, so it's
not. This is something that could happen a lot with objects that are used
all around the place and yet in each place it's decided to do a lazy
import (essentially the approach ''required'' now). Of course with the
proposed approach it would be ''better'' to do `A2=A1` instead, or in
general, only lazily import in one eagerly imported module, from where
other modules import the lazy import eagerly.
It's important to know what kind of speed penalties are involved with
using `lazy_import` because it's a speed optimization to begin with.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14187#comment:34>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
