better way to improve performance of my code

6 views (last 30 days)
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?
  4 Comments
Salvatore Mazzarino
Salvatore Mazzarino on 14 Oct 2012
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
Nathaniel on 14 Oct 2012
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.

Sign in to comment.

Answers (2)

Oleg Komarov
Oleg Komarov on 14 Oct 2012
Remove
pause(0.5)
which waits half a second, i.e. 0.5*1e7 = 5e6 = about 1388.89 hours.
  2 Comments
Salvatore Mazzarino
Salvatore Mazzarino on 14 Oct 2012
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
Salvatore Mazzarino on 14 Oct 2012
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

Sign in to comment.


Nathaniel
Nathaniel on 14 Oct 2012
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.

Categories

Find more on Argument Definitions in Help Center and File Exchange

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!