better way to improve performance of my code

I'm doing a simulation using for cycle. In this simulation I have a series of fprintf that print out information. To improve the performance of my simulation I created a custom fprintf

function custom_fprintf(debug,varargin)
%FPRINTF Summary of this function goes here
%   Detailed explanation goes here

      if debug ~= 0
          builtin('fprintf', varargin{:});        
          pause(0.5);
      end

end

When debug is setted to 1, fprintf prints out the arguments passed. The problem is that examinating my code with profiler I see that when for cycle is executed for 10e6, the simulation spend too many time in custom_fprintf function. Which could be the way to improve this situation?

[Nathaniel]

Which metric do you think is too large: total time or self time? On which line or lines in your custom function is the most time spent?

If you're running it 10e6 times with debug==1, then it would take ~58 days to complete due to pause(0.5).

Beyond that, there doesn't appear to be any reason to call builtin() to accomplish what you're doing. Just do fprintf(varargin{:});

Finally, in my experience, using varargin is significantly slower than passing arguments directly, and this is something that the profiler doesn't show. You might try to find another way to accomplish your goal. E.g., give up on the custom function idea and just wrap every call to fprintf with the if statement.

[Salvatore Mazzarino]

all my simulation works with debug value setted to 0.I use debug value setted to 1 only when I develop my code to check if everything goes well.

[Salvatore Mazzarino]

In other words, I would have a way to print out info when DEBUG is setted to 1 and print out nothing when DEBUG is setted to 0. But besides I would have good performance in the way my simulation doesn't loose time in if clause

[Nathaniel]

I understand what you're doing, although I think you're mixing 2 different patterns from compiled languages.

One pattern is that you link against either a debug library or a non-debug library, and the debug version of the code includes the print command while the non-debug version is essentially a NOOP, which gets optimized out.

The other pattern is that you have the preprocessor either compile in debug code or not based on the existence of a defined constant. In C, this would be:

#ifdef DEBUG
fprintf(...);
#endif

MATLAB is not a compiled language, so you can't build as much flexibility into your code without sacrificing some performance. That said, an if statement in which the condition is x~=0 is probably almost the fastest line of MATLAB code possible. Having your code littered with if debug~=0...end may not be the prettiest solution, but it can't possibly be any slower than calling a function which executes the same if statement.

Answer 1

[Oleg Komarov]

Remove

pause(0.5)

which waits half a second, i.e. 0.5*1e7 = 5e6 = about 1388.89 hours.

[Salvatore Mazzarino]

No I think pause is not the cause of the problem. If I setted DEBUG to 0, pause is not executed but the simulation spend my time, as profiler shows me, in if clause

[Salvatore Mazzarino]

I'm looking for a fast way to print info when debug is setted to 1 and not print info when debug is setted to 0

Answer 2

[Nathaniel]

Using varargin is what's killing you. You can get avoid this by constructing the cell array in the calling code, rather than relying on whatever mechanism MATLAB is using.

Try this for your custom_fprintf function:

function custom_fprintf(DEBUG, args)
if DEBUG
  fprintf(args{:});
end

Then call it like this:

DEBUG=false;

for n=1:1e6
  custom_fprintf(DEBUG, {'this is the format string %d\n', n});
end

This construction should be just about as fast as putting the if statement in the calling code.