Performance improvements for "isdeployed" and "persistent"?

Dear gents, I have two questions regarding performance (Matlab R2011b):

1) My personal toolbox consists of a lot of small m-code / p-code functions. Sometimes these functions are not used in native Matlab but as embedded code under Simulink. For that case I have to add lines like "coder.allowpcode..." and "coder.extrinsic..." to my functions. These lines should not have any effect if the functions are executed in native Matlab. However I found that under native Matlab these lines heavily slow the execution of my small but often called functions. To avoid that I enclosed them with "if isdeployed() ...". Unfortunately there still remains substantial execution-time overhead which is now only caused by "isdeployed()". It seems that "isdeployed()" takes about as long as a persistent declaration and doubles the execution time of my smallest functions. Do you see any possibility to get rid of that overhead? Like using compiler directives or any sort of external arrangements or avoiding that the "coder.xxx" lines are interpreted in each call?

2) Is there a possibility or work-around to speed up the execution of declarations of persistent variables?

[Kaustubha Govind]

Just to clarify, isdeployed is a MATLAB Compiler function, and is not at all related to the coder.XXX directives (which comes from MATLAB Coder). Please note that isdeployed will always return false in native MATLAB, and true when running an executable/library produced by MATLAB Compiler.

Answer 1

[Joan Puig]

Hi,

You could create a global variable that is initiated one time to gvar = isdeployed(); and then just refer to that variable through the code, so you would only have the overhead once.

Joan

[Alexander]

Hi Joan, thanks for your suggestion. Unfortunately a global declaration takes equally long as "persistent" or "isdeployed" Alex

Answer 2

[Joan Puig]

Another way you could try to do it is by having a function pointer so for example:

if isdeployed()
  myFun = @myFun_deployed();
else
  myFun = @myFun_normal();
end

But it is kind of a hack and I am not sure if it will actually be any faster

[Alexander]

But in that case we would have the overhead of "isdeployed" and the disadvantage of maintaining two functions "my_Fun..." instead of one?!

[Joan Puig]

No, you only pay the isdeployed() cost one, when you initialize the function pointers

Are you not maintaining two version of the same function for each case?

If the issue is that you want only one file, you could pass on a parameter in the function pointer

if isdeployed()
  myFun = @(inputs)myFunImpl(1,inputs);
else
  myFun = @(inputs)myFunImpl(0,inputs);
end

Answer 3

[Jan]

When I understand correctly, such code causes too much overhead for your functions:

function out = calculate(in)
persistent p_isdeployed
if isempty(p_isdeployed)
  p_isdeployed = isdeployed();
end
...
if p_isdeployed
  coder.xxx...
end

Such code will be rather slow, if you repeatedly clear the persistent variable e.g. by a clear all or clear function. But if you omit such inefficient cleanups, the overhead should be very small. Except if the actual calculation is tiny, e.g. out = in + 1 and you call this function billions of times. In this case Joan Puig's suggestion is the only usable way: Either accept the overhead for testing the deploy-status inside the function, or use two different functions.

I'm using both methods for the equivalent case that code should run efficiently under Matlab 2009a and 6.5: If the functions are large and the overhead of testing can be neglected, I test the version by the fast C-Mex FEX: isMatlabVer:

if isMatlabVer('>=', 7, 9)
  a = bsxfun(@plus, b, c)
else  % No BSXFUN in Matlab 6.5:
  a = b(:, ones(1, length(c)) + c;
end

If the overhead for testing the version would be too large (a rare case!), I create two functions, which are stored in different folders:

C:\MFiles\Matlab6.5\myfunc.m
C:\MFiles\Matlab7.9\myfunc.m

Then the function which initializes my toolboxes the matching folder is included in the path dynamically by addpath. Of course this methods will lead to an exploding complexity, if all other versions between 6.5 and 2012.b have to be considered, when this is implemented naively, but in your case you need only two folders: \myTools_deployed and \myTools_undeployed.