On Thu, Mar 14, 2013 at 11:07 PM, Chris Smith <[email protected]> wrote: > On Fri, Mar 15, 2013 at 6:24 AM, Aaron Meurer <[email protected]> wrote: >> On Thu, Mar 14, 2013 at 3:42 AM, Ondřej Čertík <[email protected]> >> wrote: >>> On Thu, Mar 14, 2013 at 12:34 AM, Aaron Meurer <[email protected]> wrote: >>>> This validates what I've often said, which is that if you use the >>>> right algorithms and the right data structures, then Python can be >>>> just as fast as a compiled alternative (especially since "the right >>>> data structures" usually means fast built-in data structures). >>>> >>>> To me, right now, there a four main things that can make SymPy slow (in >>>> order: >>>> >>>> - expand >>>> - slow matrices/linear algebra >>>> - slow polys (esp. in highly multivariate situations) >>>> - the core >>>> >>>> expand() is the worst. If we can make that faster, then all of SymPy >>>> will feel zippier. > > > This was done in the work for issue 1725, see > http://code.google.com/p/sympy/issues/detail?id=1725#c24 , but it > could never get out of review. This, like the changes to > autoexpansion, need community support and quick review of any work > because they are sympy-wide changes that become a headache to maintain > if the code base continues changing beneath them.
Perhaps you should separate those changes that add new features (like switch managers), and those changes that are designed to improve the performance, to as much degree as possible. Unfortunately, it's not so easy to do, because if we really want to be API kind, we should make most of the significant changes I suggested part of some new API. For example, we should add some way for expand methods to register quick-exit handlers. On the other hand, another way to do it would be to break the API, or at least limit it. For example, we could require that classes never change what expand methods are defined on them (i.e., no magic __getattr__). Then we could manually keep of which classes implement which methods, and quick-exit based on that. Or if we do structural caching, we'll have to assert that what expand does cannot depend on Symbol names. I haven't fully profiled expand, so this is somewhat premature. I can't say for sure what really will make it significantly faster. So we should play with that, and then move forward according to the results. Aaron Meurer > > -- > 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?hl=en. > 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
