(Bumping an unresolved issue)
You could also use bottom imports (moving the imports to the bottom of
the file), but frankly, I'd rather have imports inside functions,
unless the function is called enough that it's a performance hit.
I'm not seeing advantages here - what are they?
I see a disadvantage in that at least the parent class for any class
definition would have to be imported, so we'd now have two lists of
imports, one at the top, one at the bottom.
Sounds like in-function imports do have a noticeable impact.
This benchmark shows a potential impact of at least 600% slowdown via a
local import, possibly more if the optimized function actually reached the
import statement in a substantial fraction of cases, or if the function is
doing a lot of stuff.
Sheesh, that doesn't look good. We'd really have to determine for each
function how often it is really called in practice, which is going to slow
the whole activity to a crawl (and also bind a lot of attention in the
future).
With that background, I'd want to avoid in-function imports as far as
possible.
Yeah, well there's a reason C was created in the first place.
I hope we can do better :-)
... oh. stackoverflow for the win.
See
http://stackoverflow.com/questions/3237678/how-to-create-decorator-for-lazy-initialization-of-a-property
, the code is already available in precanned form. @read_only_lazyprop seems
to do all that we need.
You'll also want to profile that, at least for stuff in the core.
What would be a good candidate?
E.g. a test that accesses a given property for a gazillion of times.
Also consider that you might not speed things up as much as you think
because things might already be cached by the global cache.
We're currently worrying about potential slowdowns. A speedup would be a
nice side effect but I'm not worrying if it doesn't happen.
This solves the problems for attributes of classes, but what about
stuff that's at the module level?
The technique is a function that
- computes a value,
- replaces itself with that value in whatever namespace it is living in,
- returns the value.
Properties don't work on modules, but the technique should be transferrable.
If it isn't, or too unpractical to use, I think one could move the data
into a class.
(The technique as given there is probably wrong anyway. We'd want an
attribute on the class, not an attribute on each class member.)
It's something to try in real working code though.
I noticed that all import statements are run twice.
Well, maybe not all, just those that I added logging code to; it was just
half a dozen cases where I did that. Still, the outputs would always be
twice when run from bin/test.
I haven't investigated this effect at all, but if this affects not just
testing but also normal use, that could be a contributing factor to start-up
times.
I'll probably take a look as soon as I get around to doing more Python work.
Might take a while though, so feel free to investigate yourself at your
leisure :-)
Any ideas what might be causing that double-import effect?
Current worklist items:
- Find out what causes the double imports
- Implement @LazyAttribute both for modules and classes
- Benchmark lazy initialization for one attribute that's called a lot in
a test
- Get approval for @LazyAttribute
- Apply @LazyAttribute, replace C. accesses with direct lazy attribute
access
--
You received this message because you are subscribed to the Google Groups
"sympy" 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/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
