On Tue, Mar 1, 2011 at 4:56 AM, luisfe <lftab...@yahoo.es> wrote:
> On Mar 1, 1:32 pm, "Johan S. R. Nielsen" <j.s.r.niel...@mat.dtu.dk>
> wrote:
>> On Mar 1, 10:13 am, Robert Bradshaw <rober...@math.washington.edu>
>> wrote:
>>
>> Nice! I weren't aware of this module. When you get a good idea,
>> there's a good chance that someone else thought of it before ;-) I
>> like the fact that one can dynamically hack into an object's
>> namespace :-D However, lazy_import seems not to be used much (only 2-3
>> places) currently in the Sage startup (or did I grep wrongly?). Was it
>> never the intention or is it due to the overhead?
>
> Yes, it is not used much. Ideally, the way of improving sage
> startuptime would be:
>
> 1.- On first execution by a user, create a pickle of lazy_import of
> the global names and save it in the .sage directory. This should not
> be slower than current startup.
>
> 2.- Then, following executions of sage would only load that pickle
> instead of reading hundreds of different files. This will translates
> the delay from the start to the first call of the function. But note
> that you will never call each global name so globally should be
> faster...
>
> 3.- That pickle should be updated under certain conditions. By a
> command, each time sage is updated etc.
That essentially what it does, though not of the global module because
that would just be shifting the wait time from startup to first
invocation.
> Note that currently there are lazy_import(...) in the startup of sage,
> but this command does not avoid disk access of the file, only
> execution/compilation of the module to import. That is why it has
> currently low impact.
Disk access of a, or a couple, files is not the problem. Even on a
slow filesystem, that's below human perception. It's disk access of
1000s of files that's the problem.
>> Also, I didn't proofread the entire lazy_import code, but the
>> implementation seems to differ from my idea in a significant way: the
>> LazyImport object keeps wrapping the imported objects. My thought was
>> that the first time the imported object was accessed, it would replace
>> itself with the original in the global namespace, and then forward the
>> call. This way, there will be zero overhead in all later calls.
>
> No, the lazy_import object keeps wrapping the original object, but
> when accessing the lazy_import object it imports the real object in
> the namespace. So, if the lazy_import has not been referenced by
> another object then it will be collected as garbage. I do not have a
> running sage right now, but if you experiment you will see that after
> calling the object the lazy_import object disappears.
>
> It should be something like:
>
> {{{
> sage: from sage.misc.lazy_import import lazy_import
> sage: lazy_import('sage.rings.all', 'ZZ')
> sage: a = ZZ
> sage: type(ZZ)
> <class 'sage.misc.lazy_import.LazyImport'>
> sage: ZZ(4.0)
> 4
> sage: type(ZZ)
> <type 'sage.rings.integer_ring.IntegerRing_class'>
> sage: type(a)
> <class 'sage.misc.lazy_import.LazyImport'>
> }}}
Should be? It is (in the latest version of Sage :-).
- 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
