State and future of MATLAB Data API?

We've been looking into the 'C++ Matlab Data API' and it looks fairly interesting. However searching around it seems there aren't many users of this, yet, and there's not a whole of documentation except the dry API reference. So we have a couple of questions regarding it:

• is this API here to stay?
• is the API stable?
• is the API thread-safe, i.e. is it possible to call one function from thread A and call another unrelated one and not sharing data from thread B?
• is there further work planned on it? (still seems buggy in some aspects: no way to compile with all but basic warnings enabled, the documentation for MATLABLibrary::feval says the return type can be a vector but that doesn't compile, getting the sample to work requires figuring out how to set the PATH environment variable correctly but there's no information about that, ...)
• are there plans to have mcc generate C++ wrappers instead of just the ctf archive (basically, like what is done for the mwArray API now)?
• does this API use mxArray internally?

Background on this question: we have multiple desktop applications using shared libraries created by the Matlab Compiler using the 'legacy interface' aka 'C mxArray API'. Since some version newer than R2015a something changed which yields that API unusable for us (without serious amounts of work): any instance of a Matlab OOP class (i.e. something defined with classdef) stored in an mxArray will leak because mxDestroyArray does not free the memory of the class nor it's properties, anymore, it used to in versions as early as R2012 or so. We contacted Matlab support but they claim that what we do is unsupported. Which I don't really buy, mxArray has always been used to store any type, be it a number/array/cell/struct/..., and there's functions like mxGetProperty which sole purpose is getting class properties out of an instance stored in an mxArray. However we sort of need functions from the newer versions so when looking around for a solution we found that when calling our functions using the Matlab Data API there are no leaks so we're checking whether the upgrade, i.e. writing feval wrappers a hundred functions and updating callers, is worth it.

[James Tursa]

I don't have an answer for you on the C++ MATLAB Data API, but I am curious what all you are doing that is "unsupported". Is it just mxDestroyArray on a MATLAB OOP class? Or other stuff as well? You might be interested in looking at the notes in this FEX submission to see what has changed in the mxArray in R2015b and later:

https://www.mathworks.com/matlabcentral/fileexchange/67016-c-mex-matlab-version

[stijn]

Basically yes just mxDestroyArray on an OOP instance. We have Matlab functions like

function [x] = MakeClassInstance()
x = MyClass()

function [] = DoStuffWithClass(x)
x.Foo()

which get compiled using mcc into a header/lib/dll and then called like

mxArray* lhs[ 1 ];
mlxMakeClassInstance( 1, lhs, 0, NULL);
mlxDoStuffWithClass( 0, NULL, 1, lhs );
mxDestroyArray( lhs[ 0 ] );

or the mwArray equivalent. The matlab_version.h you linked to is pretty interesting but doesn't provide an immediate explanation as to why the mxDestroyArray in the above example doesn't free the instance, as it used to do. Latest news is this case has been sent to the compiler dev team but no answer yet.

[Alan Frankel]

Stijn, I hope you will be glad to hear that the memory leak you mentioned was fixed in R2019b. Thank you for reporting it. Furthermore, we are making it easier to work with classes within the MATLAB Data API C++ Shared Library. However, you are the first customer I am aware of who has asked about a code-generated interface ("C++ wrappers") for the MATLAB Data API C++ Shared Library (similar to the one for the mwArray C++ Shared Library). From what we have been hearing, the feval-based interface suits most customers' needs.

Answer 1

[Preethi Ayyamperumal]

MATLAB DATA API uses modern C++ semantics (C++11). This has several advantages over the mwArray API, including type-safety,multithread-safety, and copy-on-write semantics. MATLAB DATA API is the recommended API. However, C++ mwArray API will be supported as well.

MATLAB DATA API does not use mxArray internally. Instead, it uses matlab::data::Array. The MATLAB Data API supports C++11 features and is not compatible with the C Matrix API or MATLAB C API. You cannot mix functions from the MATLAB Data API with those in the C Matrix API or C MEX API. Likewise, you cannot mix MATLAB Data API functions with functions in the MATLAB Engine API for C or the MATLAB C API to Read MAT-File Data in a standalone application.

For questions related to the observed bugs in "feval" and status on C++ driver code for MATLAB Data API, kindly contact MathWorks technical support

[stijn]

So is it correct to say that matlab::data::Array is a whole new implementation, and matlab::data::Array itself does not use mxArray internally?

Anyway we converted one particular memory-hungry program to use the Matlab Data API and all is well. And code-wise it's indeed a good big step forward from the mwArray API.

[Freewing]

What can you say about the performance of Matlab Data API? In general, users turn to MEX functions when they lack Matlab performance. For example, I have this serious performance issue where Matlab C API performs many times faster than Matlab Data API and the latter introduces subsequent delay in Matlab execution.