New LazyImport implementation based on lazy_object_proxy

[embray]

This adds lazy_object_proxy as a dependency (see #22792), and rewrites the sage.misc.lazy_import.LazyImport class on top of it. This doesn't change anything else about how the lazy_import mechanism is implemented and is mostly independent of any such changes (e.g. #22752).

Pros

• In the spirit of tickets like Use psutil instead of various hacks #21805, removes more code than it adds, replacing Sage-specific code with robust solutions from the Python community...

• ...meaning less code for us to maintain and keep forward-compatible with future Python versions (in principle, but see also the first "con").

• This solution is probably faster, being written purely in C and with no Cython-related overhead. The old implementation in Sage required a function call for every indirection to the proxied object (albeit a cpdef function). The lazy_object_proxy implementation in principle also has a plain C function call (Proxy__ensure_wrapped), but with typical compiler optimizations this is actually eliminated entirely for the common case where the proxied object has been initialized. I haven't done any benchmarks though, but could if requested.

• Maintainer is an active member of the Python community and not likely to abandon the project or disappear (hard to quantify of course, but he's someone whose work I'm familiar with).

Cons

• Effectively same amount of code to maintain if we ever need upstream changes for Sage--upstream can be more difficult to deal with than fixing code in Sage.

That said, the implementation of lazy_object_proxy is very generic and not likely to require deep changes for Sage. The old LazyImport has never required deep structural changes either.

Depends on #22792

Component: misc

Author: Erik Bray

Branch/Commit: u/embray/lazy-import-proxy @ e58d61d

Issue created by migration from https://trac.sagemath.org/ticket/22793

[jdemeyer]

comment:1

Won't this conflict with #22755?

[embray]

comment:2

Probably; I didn't see that ticket.

[embray]

comment:3

Probably; I didn't see that ticket.

[embray]

Description changed:

[embray]

comment:4

I mean, I would say this mostly supersedes #22755, though there are some changes from that ticket that would still be applicable, and I could integrate.

[jdemeyer]

comment:5

Do you have further plans regarding lazy imports?

I would very much like to have an implementation of lazy imports which works in Cython. At this point, it's not clear to me whether this ticket makes that easier or harder. So I'd prefer to leave this ticket pending until somebody provides a Cython implementation of lazy imports based on this Proxy object.

[embray]

comment:6

I do, but they're not 100% dependent on this; it was just an idea. What do you mean, in this case, by "works with Cython"?

[jdemeyer]

comment:7

Replying to @embray:

I do, but they're not 100% dependent on this; it was just an idea.

Right, I do agree that the implementation of the lazy import mechanism (lazy_import) and the lazy object (class LazyImport) is mostly orthogonal. But it's also not 100% orthogonal, and the details might matter.

What do you mean, in this case, by "works with Cython"?

As I wrote on #22752, an implementation of the lazy import mechanism which works equally well for Python and Cython.

[jdemeyer]

Replying to @embray:

• This solution is probably faster

Arithmetic is actually about a factor 3 slower...

With #22755:

sage: from sage.misc.lazy_import import LazyImport; sage.all.one = 1; a = LazyImport('sage.all', 'one'); timeit('a+a', number=1000000, repeat=100)
1000000 loops, best of 100: 81.1 ns per loop

With #22793:

sage: from sage.misc.lazy_import import LazyImport; sage.all.one = 1; a = LazyImport('sage.all', 'one'); timeit('a+a', number=1000000, repeat=100)
1000000 loops, best of 100: 220 ns per loop

To be honest, this surprised me too. Maybe it's because of the Python subclass LazyImport on top of Proxy?

For completeness, with vanilla Sage 8.0.beta0:

sage: from sage.misc.lazy_import import LazyImport; sage.all.one = 1; a = LazyImport('sage.all', 'one'); timeit('a+a', number=1000000, repeat=100)
1000000 loops, best of 100: 175 ns per loop

[nbruin]

comment:9

Possible cause for the slowdown: the overhead of the factory function, which is a full-blown python function call, rather than the cdef _get_object we had originally. It looks like the the right amount of overhead (python function calls are expensive, and we're getting two of them in the benchmark).

Of course, the whole idea of LazyImport is that the proxy shim removes itself, which is carefully avoided in the test above. So we are benchmarking something that should be avoided ...

[jdemeyer]

comment:10

Replying to @nbruin:

Possible cause for the slowdown: the overhead of the factory function, which is a full-blown python function call

If I understand things correctly, the factory function should only be called once for a given object, so that shouldn't matter.

[jdemeyer]

comment:11

The overhead from the Python subclass is significant:

sage: from lazy_object_proxy import Proxy
sage: class PyProxy(Proxy): pass
sage: def factory(): return 1
sage: a = Proxy(factory); timeit('a+a', number=1000000, repeat=100)
1000000 loops, best of 100: 82.7 ns per loop
sage: a = PyProxy(factory); timeit('a+a', number=1000000, repeat=100)
1000000 loops, best of 100: 222 ns per loop

So, the Proxy is equally fast as LazyImport, but the additional Python subclass makes it a lot slower.