Speed processing if algorithm is partitioned in well-organized minor functions
1 view (last 30 days)
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?
Cedric Wannaz on 24 Oct 2017
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.
>> 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.