Thanks for all the help.

That said, I'm not sure it is an issue of the strides. I can easily recreate the slowdown as in the above gist ( https://gist.github.com/da7b2ef6ef109511af06a9cebbfc8ed1 ). Also, modifying the flags of a user-created ndarray so they agree with the loaded one is still noticably faster than using the array from `scipy.io.loadmat`

For my purposes, a copy is just fine, but I think this might be an issue that could be looked into. Perhaps I should file an issue on github?

On Sat, Aug 26, 2017 at 11:06 AM, Robert Kern <robert.kern@gmail.com> wrote:

On Sat, Aug 26, 2017 at 12:09 AM, Jonathan Taylor <jonathan.taylor@stanford.edu> wrote:
>
> Yes, it's a dense 2500x2000 matrix.
>
> Loaded strides: (8, 16000)
>
> Copied strides: (20000, 8)
>
> So, matvec is just slower because of strides and where numpy retrieves data? Is there a simple way to do this besides a copy? I can easily afford the copy, just wondering.

It's not simpler, but the most efficient and idiomatic way to ensure C-contiguity is to use np.ascontiguousarray(). This will make a copy only if necessary.

--
Robert Kern

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev

Jonathan Taylor
Dept. of Statistics
Sequoia Hall, 137
390 Serra Mall
Stanford, CA 94305
Tel: 650.723.9230
Fax: 650.725.8977
Web: http://www-stat.stanford.edu/~jtaylo