[Numpy-discussion] Performance problems with strided arrays in NumPy

faltet at xot.carabos.com faltet at xot.carabos.com
Sat Apr 15 10:29:01 EDT 2006


On Sat, Apr 15, 2006 at 07:55:46AM -0700, Tim Hochberg wrote:
> >I'm not sure this is directly related with striding. Look at this:
> >
> >In [5]: npcopy=timeit.Timer('a=a.copy()','import numpy as np;
> >a=np.arange(1000000,dtype="Float64")[::10]')
> >
> >In [6]: npcopy.repeat(3,10)
> >Out[6]: [0.061118125915527344, 0.061014175415039062,
> >0.063937187194824219]
> >
> >In [7]: npcopy2=timeit.Timer('b=a.copy()','import numpy as np;
> >a=np.arange(1000000,dtype="Float64")[::10]')
> >
> >In [8]: npcopy2.repeat(3,10)
> >Out[8]: [0.29984092712402344, 0.29889702796936035, 0.29834103584289551]
> >
> >You see? assigning to a new variable makes the copy go 5x times
> >slower! 
> >
> You are being tricked! In the first case, the array is discontiguous for 
> the first copy but for every subsequenc copy is contiguous since you 
> replace 'a'. In the second case, the array is discontiguous for every copy

Oh, yes!. Thanks for noting this!. So in order to compare apples with
apples, the difference between numarray and numpy in case of strided
copies is:

In [87]: npcopy_stride=timeit.Timer('b=a.copy()','import numpy as np;
a=np.arange(1000000,dtype="Float64")[::10]')

In [88]: npcopy_stride.repeat(3,10)
Out[88]: [0.30013298988342285, 0.29976487159729004, 0.29945492744445801]

In [89]: nacopy_stride=timeit.Timer('b=a.copy()','import numarray as np;
a=np.arange(1000000,type="Float64")[::10]')

In [90]: nacopy_stride.repeat(3,10)
Out[90]: [0.07545709609985351, 0.0731458663940429, 0.073173046112060547]

so numpy is aproximately 4x times slower than numarray.

Cheers,

Francesc




More information about the NumPy-Discussion mailing list