On 23.04.2013 16:30, Ronan Lamy wrote:
Le 22/04/2013 10:27, Tom Bachmann a écrit :
I attach the output. Here is my reading:
- simplify spends 70% in together and powsimp
- together spends 99% in object creation
- powsimp spends 95% in object creation
- AssocOp.__new__ spends 90% in flatten
- flatten has now obvious hotspot
What I can see is that flatten spends considerable amounts of time in
things which recursively call flatten *again* (i.e. things like a *= b).
This seems to indicate that it can probably benefit from memoization
caching.
Memoization won't achieve anything, Mul is already cached.
Well but this whole benchmark is with caching disabled ;). My comment
was in the context of "can we be as fast as current sympy master by
using a form of localized caching that is safe with the new assumptions
system".
My implicit question was how much our performance would decrease if we
cleared the cache after every (recursive family) flatten call (i.e.,
memoize it in Aaron's terminology). My answer now (from the experiments
I conducted) is that this is most likely insufficient, i.e. that the
cache clearing has to be done higher up (so that flatten is memoized
*across* independent calls to it).
We need to
find a way to avoid O(n) operations (like <Mul> *= b) in the first
place. Also, Mul.flatten does way too many things and has way too many
special cases. Rational powers simplification shouldn't be done there
and things like I * zoo shouldn't have to go through Mul.flatten.
I wholeheartedly agree. But I'm trying hard not to propose a core
redesign as my gsoc project :-).
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
