MATLAB Answers

better way to improve performance of my code

7 ビュー (過去 30 日間)
Salvatore Mazzarino
Salvatore Mazzarino 2012 年 10 月 14 日
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 件のコメント

表示 1 件の古いコメント
Salvatore Mazzarino
Salvatore Mazzarino 2012 年 10 月 14 日
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
Salvatore Mazzarino 2012 年 10 月 14 日
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 2012 年 10 月 14 日
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.

回答 (2 件)

Oleg Komarov
Oleg Komarov 2012 年 10 月 14 日
Remove
pause(0.5)
which waits half a second, i.e. 0.5*1e7 = 5e6 = about 1388.89 hours.

  2 件のコメント

Salvatore Mazzarino
Salvatore Mazzarino 2012 年 10 月 14 日
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 2012 年 10 月 14 日
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 2012 年 10 月 14 日
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.

  0 件のコメント

Sign in to comment.

タグ


Translated by