The reason I ended up learning about order='C' vs order='F' was not because I was trying to optimize for speed — it’s because I’m trying to represent existing layouts in memory accurately.

I don’t have any evidence that either of these would be any faster, and it’s not clear why that would be so.

Of course, you do want the data laid out in memory such that you tend to access it in sequential order in memory, because of locality of reference. If you knew you were always accessing the data in a certain order, but had some API that needed a different order of indices, then using order='F' might be useful.

In my recent work, the idea is to be able to use large WAVE files, or very large RAW audio files, without bringing them into memory, by using memory-mapped files.

For stereo, this naturally gives you an Nx2 shaped array, but many DSP programs want 2xN arrays, so the order parameter was a logical way to achieve that in-place.

I’m actually spinning off some of this into another project this week: https://github.com/rec/wavemap

Memory-mapped files work extremely well with numpy. I have a 300GB RAW audio file that I’ve done calculations on as if it were all in memory — it was mind-blowing. In particular, slicing is still O(1), even with billions of entries.

Thanks for an excellent article.