Re: [off topic] Re: [Numpy-discussion] numarray speed - PySequence_GetItem

[Sebastian H. <ha...@ms...>]

On Monday 28 June 2004 12:03 pm, Todd Miller wrote:
> On Mon, 2004-06-28 at 13:59, Chris Barker wrote:
> > Sebastian Haase wrote:
> > > BTW, from the profiling/timing I did you can tell that wxPyPlot
> > > actually plots 25000 data points in 0.1 secs - so it's _really_ fast
> > > ...
> >
> > Actually, it's probably not that fast, if you are timing on
> > Linux/wxGTK/X-Windows. X is asyncronous, so what you are timing is how
> > long it takes your program to tell X what to draw, but it may take
> > longer than that to actually draw it. However, what you are timing is
> > all the stuff that is effected by numarray/Numeric.
> >
> > I worked on part of the wxPython DC.DrawXXXList stuff, and I really
> > wanted a Numeric native version, but Robin really didn't want an
> > additional dependency. We discussed on this list a while back whether
> > you could compile against Numeric, but let people run without it, and
> > have it all work unless Someone actually used it. What makes that tricky
> > is that the functions that test whether a PyObject is a Numeric array
> > are in Numeric... but it could probably be done if you tried hard enough
> > (maybe include just that function in wxPython...)
>
> numarray-1.0 has two macros for dealing with this:  PyArray_Present()
> and PyArray_isArray(obj).  The former (safely) determines that numarray
> is installed, while the latter determines that numarray is installed and
> that obj is a NumArray.  Both macros serve to guard sections of code
> which make more extensive use of the numarray C-API to keep them from
> segfaulting when numarray is not installed.  I think this would be easy
> to do for Numeric as well.
>
> One problem is that compiling a "numarray improved" extension requires
> some portion of the numarray headers.  I refactored the numarray
> includes so that a relatively simple set of 3 files can be used to
> support the Numeric compatible interface (for numarray).  These could
> either be included in core Python (with a successful PEP) or included in
> interested packages.  This approach adds a small source code burden
> somewhere,  but eliminates the requirement for users to have numarray
> installed either to run or compile from source.
>
> I'll send out the draft PEP later today.
>
> Regards,
> Todd

My original question was just this: Does anyone know why numarray is maybe 10 
times slower that Numeric with that particular code segment 
(PySequence_GetItem) ?

- Sebastian