A Dimecres 20 Desembre 2006 07:59, David Cournapeau escrigué:
Could you detail a bit how you did the profiling with oprofile ? I don't
manage to get the same results than you (that is on per application
basis when the application is a python script and not a 'binary' program)
Sure. You need
Francesc Altet wrote:
A Dimecres 20 Desembre 2006 07:59, David Cournapeau escrigué:
Could you detail a bit how you did the profiling with oprofile ? I don't
manage to get the same results than you (that is on per application
basis when the application is a python script and not a 'binary'
A Dimecres 20 Desembre 2006 03:36, David Cournapeau escrigué:
Francesc Altet wrote:
A Dimarts 19 Desembre 2006 08:12, David Cournapeau escrigué:
Hi,
Following the discussion on clip and other functions which *may* be
slow in numpy, I would like to know if there is a way to easily
David == David Cournapeau [EMAIL PROTECTED] writes:
David Of this 300 ms spent in Colormap functor, 200 ms are taken
David by the take function: this is the function which I think
David can be speed up considerably.
Sorry I had missed this in the previous conversations. It is
I added a ticket for Francesc's enhancement:
http://projects.scipy.org/scipy/numpy/ticket/403
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Francesc Altet wrote:
seems to tell us that memmove/memcopy are not called at all, but
instead the DOUBLE_copyswap function. This is in fact an apparence,
because if we look at the code of DOUBLE_copyswap (found in
arraytypes.inc.src):
@[EMAIL PROTECTED] (void *dst, void *src, int swap, void
A Dimecres 20 Desembre 2006 19:32, Andrew Straw escrigué:
I added a ticket for Francesc's enhancement:
http://projects.scipy.org/scipy/numpy/ticket/403
Thanks Andrew, but I realized that my patch is not safe for dealing
with unaligned arrays (Sun machines would segfault). After thinking
several
On 12/20/06, Francesc Altet [EMAIL PROTECTED] wrote:
A Dimecres 20 Desembre 2006 03:36, David Cournapeau escrigué:
Francesc Altet wrote:
A Dimarts 19 Desembre 2006 08:12, David Cournapeau escrigué:
Hi,
snip
@[EMAIL PROTECTED] (void *dst, void *src, int swap, void *arr)
{
On 12/19/06, Francesc Altet [EMAIL PROTECTED] wrote:
A Dimarts 19 Desembre 2006 08:12, David Cournapeau escrigué:
Hi,
snip
My guess is that the real bottleneck is in calling so many times
memmove (once per element in the array). Perhaps the algorithm can be
changed to do a block copy
Charles R Harris wrote:
My guess is that the real bottleneck is in calling so many times
memmove (once per element in the array). Perhaps the algorithm can be
changed to do a block copy at the beginning and then modify only the
places on which the clip should act (kind of
David == David Cournapeau [EMAIL PROTECTED] writes:
David At the end, in the original context (speeding the drawing
David of spectrogram), this is the problem. Even if multiple
David backend/toolkits have obviously an impact in performances,
David I really don't see why a numpy
John,
The current version of __call__ already includes substantial speedups
prompted by David's profiling, and if I understand correctly the present
bottleneck is actually the numpy take function. That is not to say that
other improvements can't be made, of course.
Eric
John Hunter wrote:
Francesc Altet wrote:
So, cProfile is only showing where the time is spent at the
first-level calls in extension level. If we want more introspection on
the C stack, and you are running un Linux, oprofile
(http://oprofile.sourceforge.net) is a very nice profiler. Here are
the outputs for
13 matches
Mail list logo
