On Sat, Jul 20, 2013 at 6:23 AM, Joachim Durchholz <[email protected]> wrote: > (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.
The disadvantage is readability. The advantage is that the import is only run once, at import time. > > >>> 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. Yeah. Or just profile SymPy in general (that will give you an idea of what is *actually* used, which a contrived example won't). > > >> 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. Also balance it against the speedup we get by removing the metaclass that injects things into C. > > >> 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. I doubt there are many module level variables that are not functions anyway (except for all the ones that are classes). Aaron Meurer > > 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. > > -- 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.
