Speed processing if algorithm is partitioned in well-organized minor functions

Hi everyone!

I need to process tons of data per second in an Software-Defined Radio (SDR) scheme I am designing.

I have asked a more experienced friend If the organization of my algorithm in minor functions would slow down the processing flux. He answered me "NO", but when I implemented the function-partitioned algorithm, my SDR hardware indicated me a drop on performance and a congestion in data stream.

I would be very thankful if someone explain me if the division of a algorithm in minor functions slow down or not the processing. Could someone tell me the reasons, what really happen etc?

Thanks!

[Rik]

I'm not an expert, but I would say splitting your algorithm will very subtly slow down your code, because of the creation of a new function stack etc. The speed up can be found in the advantages of modular programming (i.e. easier debugging and optimizing of parts of your code).

[John D'Errico]

This is far too vague a question to give any useful answer.

Well written code, using a good algorithm design will be efficient, regardless if you split things up into functions or not. (Subject to a caveat or two. Well written code requires the author to fully understand the language and how to make good use of the abilities of that language.)

So when you use functions, that means you need to understand how to pass data around between those functions. It means you need to be careful when you work with large data sets. MATLAB does not copy your data when you do a function call unless you modify the data.

Function call overhead is pretty low. But of course if you call a function that does relatively little, but you call it millions of times, you can easily cause a problem, essentially tossing CPU cycles into the bit bucket.

So, yes, functions can slow things down in SOME cases. But really, that is just a reflection of poorly written code, that does not use the language properly. You can always write crap as code, regardless of whether it is split into functions.

That you had a problem when you used functions in this respect probably just says you did a poor job in writing the code.

[Rafael Mello]

Rik Wisselink and John D'Errico, my very thanks for trying to help me. It seems that the call of the function does not take just a little time, so if the job of the function is a simple one, it does not worth.

Answer 1

[Cedric Wannaz]

Part of programming consists in understanding where and how code can be segmented into simple self-consistent functional blocks. That means understanding where the overhead due to function calls is negligible in regard to the rest of the processing time. If you are iterating through almost trivial operations, don't wrap these operations in a function because the overhead will stack and dominate the time necessary for the rest of the (trivial) processing:

 >> a = 1 ;
 >> tic ; for k = 1 : 1e8,  a = a + 1 ;  end ;  toc
 Elapsed time is 0.268869 seconds.

 >> a = 1 ;
 >> plus1 = @(x) x+1 ;    % Define a function inline for the example.
 >> tic ; for k = 1 : 1e8,  a = plus1(a) ;  end ;  toc
 Elapsed time is 36.841811 seconds.

Versus

 >> v = rand( 1, 1e5 ) ;

 >> tic ; for k = 1 : 1e4, a = fft(v) ; end ; toc
 Elapsed time is 4.794085 seconds.

 >> myFft = @(x) fft(x) ;
 >> tic ; for k = 1 : 1e4, a = myFft(v) ; end ; toc
 Elapsed time is 4.806311 seconds.

[Rafael Mello]

Very informative examples Cedric Wannaz! Thanks!

[Cedric Wannaz]

My pleasure!

[Ara]

It is, indeed, very informative examples. Thanks, Dr. Cedric Wannaz.