On Fri, Apr 20, 2012 at 1:22 PM, Tom Bachmann <e_mc...@web.de> wrote: > >>> Sure. But I think (possibly contrary to what I said earlier), staircase >>> really isn't the problem. If the result is huge then the next parts >>> (calling >>> reduced(), solving the linear system) are going to take ages as well. >> >> >> Maybe we should run kernprof on it to see what function calls are >> really taking up the most time. >> > > I'm using mprofile. But it's not all that easy to decipher where the problem > is (even from a nice graph *g*), or if there even is a real problem (an > algorithm that suffers combinatorial explosion simply is not going to work > with large expressions...).
What is mprofile? I didn't find it by Googling. I think it's useful. This will tell us which algorithms we need to focus on optimizing. Even if the algorithm itself can't really be improved, there are likely a lot of little things we can do to make things faster. For example, something as simple as rewriting a recursive function non-recursively can make a huge difference (especially if it's one in the core of the polys). I've also found quite often that the problem lies in some trivial inefficiency because someone coded up a simple algorithm in a naive way. Aaron Meurer > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
