[Numpy-discussion] A comparative test

[Rick White]

On Thu, 6 Oct 2005, Francesc Altet wrote:

> A Dijous 06 Octubre 2005 20:55, Colin J. Williams va escriure:
> > RESULTS:
> >  >pythonw -u "NumericNumarrayTest.py"
> >
> > Timer-Numeric23.8: 0.179712784725
> > Timer-numarray1.3.3: 0.21674933546
> > Timer-Numeric3: 0.253077136899
>
> Is that really true? From my original post:
>
> >>> from timeit import Timer
> >>> setup = "import Numeric; a = Numeric.arange(2000);a.shape=(1000,2)"
> >>> Timer("for i in range(len(a)): row=a[i]", setup).timeit(number=100)
>  0.12782907485961914
> >>> setup = "import numarray; a = numarray.arange(2000);a.shape=(1000,2)"
> >>> Timer("for i in range(len(a)): row=a[i]", setup).timeit(number=100)
>  1.2013700008392334
>
> My post was from January, so, in the interim numarray has improved *a
> lot* it's object creation time. In that case, why the numarray team
> hasn't publisized that more? Well, I think I should be missing
> something. Time for nap.

Well, this seems pretty clear:

On Thu, 14 Apr 2005, Todd Miller wrote:

> Subject: [Numpy-discussion] ANN: numarray-1.3.0
>
> I. ENHANCEMENTS
>
> 2. Removal of dictionary update from array view creation improves
> performance of view/slice/subarray creation.  This should e.g. improve
> the performance of wxPython sequence protocol access to Nx2 arrays.

You might wonder why everyone didn't notice when their numarray
programs started to run blazingly fast after 1.3.0.  My (jaded)
view is that it is very rare to have an application where the overall
execution time is dominated by the time to create small arrays.
When you're in that limit, there are a million other overheads that
are also slowing you down.  In the vast majority of applications
you could reduce the array creation time to zero and probably
wouldn't notice the difference without running timing tests.

IMHO the numarray developers put their emphasis in the right place
by focusing on large array performance and improved functionality,
and all the noise around small array indexing performance was just
a red herring that convinced some folks not to try numarray because
they heard it was slow.  I hope Travis doesn't devote a lot of
effort to this optimization right now.  I'd be much more interested
in seeing a large array benchmark.
				Rick