Slow Matlab R2018b TypedArray array access in C++

Question

I am using MATLAB R2018b mex functions to integrate a C++ library with my MATLAB code. As part of that, I need to take data in a MATLAB array and save into a C++ pointer array and a C++ vector of structures. However, mapping the matlab typed array is proving to be very slow (~0.4 seconds for ~800,000 elements).

here is the relevant code

const matlab::data::TypedArray<float> Vertices = std::move(inputs[0]); 
float* positions = new float[Vertices.getNumberofElements()];
for (size_t i = 0; i < Vertices.getDimensions()[0]; i ++)
{
    ctr = 9 * i;
    positions[ctr + 0] = Vertices[i][0];
    positions[ctr + 1] = Vertices[i][1];
    positions[ctr + 2] = Vertices[i][2]; 
}

What is causing this loop to be slow? I tried re-ordering array access for Vertices to try and make the code more cache friendly, but that didn't produce a meaningful speed-up. Right now, the loop is ~0.4ms for 800,000 elements, ideally memory copy should take far less time, right?

When I looked over previous advice, I found that most answers use older mex functions, where the new(?) MATLAB C++ API doesn't have the same functions or structure.

Edit:

I followed Cris' advice and used a loop over iterators, that increased speed by about half, to 0.14 seconds.

The new code I'm using is:

    const matlab::data::TypedArray<float> Vertices = std::move(inputs[0]); 
    float* positions = new float[Vertices.getNumberofElements()];
for (auto it = Vertices.begin(); it != Vertices.end(); ++it)
{
    positions[ctr] = *it; 
    ++ctr; 
} 

So it is faster, but still surprisingly slow (0.14 seconds for 800,000 elements). Is there any other way to speed this loop?

Answer 1

I got a major speedup by applying Cris advice and using the following code:

const matlab::data::TypedArray<float> Vertices = std::move(inputs[0]);
float* positions = new float[Vertices.getNumberofElements()];
memcpy(positions,&*Vertices.begin,sizeof(float)*Vertices.getNumberofElements());

Runtime went from 0.14 (using standard Visual Studio optimization) to 0.0035, which is acceptably fast for my application.