On Fri, Apr 20, 2012 at 2:17 PM, Tom Bachmann <e_mc...@web.de> wrote:
> On 20.04.2012 20:31, Aaron Meurer wrote:
>>
>> 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'm sorry ^^. It's cProfile. (I run it via python -m cProfile ... got the
> letters mixed up in my head).

Oh, I know about that one :)  But what graph did you get?  From my
experience, kernprof gives much nicer output, and it's really easy to
use (you just decorate the functions you want to profile).  You can
even get output to kcachegrind if you want something more graphica.

Note that kernprof and cProfile are a little different.  cProfile
profiles function calls, and makes no discrimination where they are.
kernprof profiles lines, and only does it for those functions that you
decorated.

Aaron Meurer

>
>
>> 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.
>>
>
> Absolutely. I'll see what I can find out.
>
>
>> 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.
>

-- 
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.

Reply via email to