Re: More efficient MEX or MEX-like interface

[John W. Eaton]

On 30-Sep-2008, David Bateman wrote:

| Taking a quick look at the code I see a couple of other major sources of 
| inefficiency.
| 
| 1) prhs in the call to mexFunction causes a copy of the octave_value 
| data in all cases, not just for complex data. For example consider the 
| code from ov-re-mat.cc
| 
| mxArray *
| octave_matrix::as_mxArray (void) const
| {
|   mxArray *retval = new mxArray (mxDOUBLE_CLASS, dims (), mxREAL);
| 
|   double *pr = static_cast<double *> (retval->get_data ());
| 
|   mwSize nel = numel ();
| 
|   const double *p = matrix.data ();
| 
|   for (mwIndex i = 0; i < nel; i++)
|     pr[i] = p[i];
| 
|   return retval;
| }
| 
| It would be good is we could also have a use methods like
| 
| const mxArray *
| octave_matrix::as_mxArray (void) const
| {
|   mxArray *retval = new mxArray (mxDOUBLE_CLASS, dims (), mxREAL);
|   retval.set_data (matrix.fortran_vec ());
|   return retval;
| }
|  
| and we'd need an appropriate const version of set_data added to the mex 
| interface. Is this possible or am I missing something?

Yes, you could get the data this way without having to copy if you
promise not to change the data through the pointer that is returned
(that's what the const qualifier here will do, yes?).  So that can
help to improve efficiency for an extended MEX interface, but not for
the original MEX interface (as I recall, anyway).

| 2) The memory allocated with mxCalloc, etc internally to a mex function 
| must be copied to an octave_value when leaving the function, as mxCalloc 
| allocate with ::calloc, etc (or rather ::malloc and memset). This 
| doesn't play well with the C++ new/delete method of allocating memory 
| which is the reason for the need for the copy. Frankly, I don't see an 
| easy way of addressing this.

Nor do I, if the definition of mxCalloc states that it uses malloc.
If it just says that it allocates some memory and zeros it, then I
suppose we could use new and memset.  But to avoid a copy, I think we
would also need new constructors in the Array and octave_value
classes that take a pointer to some allocated memory and a set of
dimensions.  I've resisted that in the past because it violates the
principle of having the Array and octave_value classes own their data
so that they can provide some guarantees about consistency of the data
(i.e., the size actually matches what was allocated).

jwe