[Numpy-discussion] Speed performance on array constant set

[Todd Miller]

Mark Heslep wrote:

> Travis Oliphant wrote:
>
>>> 1. numdata.h  example that works well for simple Cv structures  
>>> containing uniform types:  CvPoint2D32F  => struct { float x, float 
>>> y }.  Can I use a record array here, or is there some Numpy overhead 
>>> interlaced with fields?
>>
>>
>>
>> You can use a record array, but for uniform types I don't know what 
>> the advantage is (except for perhaps named-field slicing---which may 
>> actually be faster I'm not sure) over a x2 float array.
>
>
> So that I can step through the array record by record and not field by 
> field.
>
>>> 2. numarray.h  Attempt to replace the main Cv Image structures 
>>> CvMat, IplImage.  Needs work. Some success but there's segfault or 
>>> two in there somewhere.
>>
>>
>> These can be ported fairly easily, I think (actually, the old Numeric 
>> typemaps would still work --- and work with Numarray), so the basic 
>> Numeric C-API still presents itself as the simplest way to support 
>> all the array packages.
>
>
> Well good to know.  Ive been proceeding directly from the NumArray 
> Users Manual 1.5 by Greenfield/Miller et al that describes the NA High 
> Level API as the fastest of the APIs available to NA.  

The Numeric compatibility layer in numarray is almost identical in 
performance with the High Level API.   I recommend using the Numeric 
compatibility layer because it makes it easier to port your application 
back to Numeric or forward to NumPy.

> I thought that NA also took steps to insure that unnecessary mem 
> copies were not made, unlike Numeric?

NA does provide flexibility and support for managing mis-behaved 
(byteswapped, mis-aligned, mis-typed) arrays,  but these extra 
properties weren't a concern for Numeric.  Both numarray's High Level 
API and numarray's Numeric compatibility layer generally make whole 
copies of arrays as required to present well behaved representations of 
data to C.


Regards,
Todd