Performance of MEX versus builtin functions

When Matlab calls a MEX file, is there overhead that makes the call slower as compared to a built-in binary like min, max, etc...?

Similarly, if a MEX file calls a built-in function (via mexCallMATLAB), will it be slower to launch than if you had called the same builtin function directly from within Matlab?

Answer 1

[James Tursa]

I don't know the answer to your first question. But I would expect the overhead for the mex function entry (other than loading into memory) to be minimal based on how fast mex functions seem to run in practice.

For the second question, there is a gotcha. When calling functions (built-in or otherwise) from MATLAB m-files (or p-files I suppose), the normal data sharing rules seem to be in play. E.g., the reshape( ) function when acting on full variables returns some type of shared data copy. So it is relatively fast. HOWEVER, it is my belief based on past experience that mexCallMATLAB will always return deep data copies even when circumstances (such as reshape( )) could have returned some type of shared data copy. My guess is that this is a hard philosophy for mex routines. Otherwise, how would the user/programmer know when it was safe to modify the results of the call in-place? They can't, since there is no official mechanism to detect data sharing. So, in addition to the extra overhead of the mexCallMATLAB( ) call itself, there are these potential forced deep data copies that can make a function called from a mex routine much slower than calling from an m-file.

I believe the C++ interface for calling MATLAB functions operates differently. I don't use the C++ interface myself because it doesn't allow enough control of memory allocation/deallocation to my liking, but it is my impression that they attempted to imitate the lazy copy rules from the MATLAB level in this interface.

[Matt J]

Thanks, James. Regarding the first point, it would surprise you then that my mex_min (attached) runs much more slowly than the native min()?

x=rand(5,1);

tic
 testLoop(@min,x)
toc

tic
 testLoop(@mex_min,x)
toc

Elapsed time is 0.021670 seconds.

Elapsed time is 0.947045 seconds.

function testLoop(fcn,x)


  for i=1:1e6
    fcn(x);
  end


end

[James Tursa]

It doesn't surprise me that calling a mex routing might be a little slower, but your timings seem too disparate. I am getting this in R2021a with MinGW64:

>> testLoop_driver
Elapsed time is 0.281844 seconds.
Elapsed time is 0.529341 seconds.

And if I compile with the -R2018a flag, this:

>> testLoop_driver
Elapsed time is 0.277256 seconds.
Elapsed time is 0.506919 seconds.

Since there are no complex variables involved, I didn't expect any significant difference with the -R2018a flag, and indeed I am not seeing any.

If you average the difference per call, it amounts to about .25/1e6 = 2.5e-7 seconds per call. I don't see anything overly egregious with that. Your results, however seem suspicious. I can't explain a difference that large. Maybe the MATLAB min unrolls the loop for small sizes in your version? Or maybe it is just the mex interface? Hard for me to tell.

I would point out that you also need to check for mxIsSparse(prhs[0]) in your argument checks. Otherwise your mex routine can crash.

And if you want to be able to compile the routine with or without the -R2018a flag, use (double *) mxGetData(etc.) instead of mxGetPr(etc.)

[Matt J]

There were a variety of optimizations in R2023, I seem to recall. Perhaps you are missing those in R2021? I was running in R2024b. We can also run the test right here to see how it fares in R2025:

unzip mex_min.zip
mex -O mex_min.c

Building with 'gcc'.
MEX completed successfully.

x=rand(5,1);

 timeit(@()test1(x))

ans = 0.0166

 timeit(@()test2(x))

ans = 0.7208

function test1(x)
  for i=1:1e6
    min(x);
  end
end

function test2(x)
  for i=1:1e6
    mex_min(x);
  end
end

[James Tursa]

Well, the results are what they are. Yes, it does seem that the updates have affected the mex timing, unfortunately. TMW removed the shared data linked lists from the mxArray header a few years ago, so that has dumbed down what you can do in a mex routine. And now the interface itself has apparently slowed down. Sigh ...