Which way of programming is more efficient and faster?

1 Ansicht (letzte 30 Tage)
Amirhossein Moosavi
Amirhossein Moosavi am 2 Jul. 2019
Bearbeitet: Jan am 2 Jul. 2019
Dear friends,
I would like to know whether there is a difference between following cases. Your responses are appreciated.
Case 1
X = 1;
Y = X + 4;
Z = X + Y;
Case 2
X = 1; Y = X + 4; Z = X + Y;
Other cases that I want to compare are as follows:
Case 3
v1 = k1{t};
nVar = size(v1, 2);
CP = randsample(nVar-1, 2);
Case 4
CP = randsample(size(k1{t}, 2)-1, 2);
  7 Kommentare
Guillaume
Guillaume am 2 Jul. 2019
Bearbeitet: Guillaume am 2 Jul. 2019
Attached, a proper test code. It repeats each test a 10000 times (otherwise timeit warns you that the timing uncertainty is too big, and test the timing 5 times. Here is the output on my machine:
>> testtiming
Code on multiple lines: 3.99263e-05
Code on a single line: 4.61002e-05
Code on multiple lines: 9.43913e-06
Code on a single line: 8.98619e-06
Code on multiple lines: 8.91961e-06
Code on a single line: 8.437e-06
Code on multiple lines: 8.50375e-06
Code on a single line: 1.23205e-05
Code on multiple lines: 1.23055e-05
Code on a single line: 9.3873e-06
I'd say it's a tie as expected.
Note that because of the JIT compiler these timings can't be relied on for real world use case anyway.
"and it is optimized way of writing the code"
Certainly not. As I answered the optimisation you should focus on is clarity, not speed. Focusing on speed before you've proven that speed is a problem is not a good way to write code. In any case, even if there were differences, they would be so minutes as to be completely undetectable by the user.
Stephen23
Stephen23 am 2 Jul. 2019
Bearbeitet: Stephen23 am 2 Jul. 2019
"Which way of programming is more efficient and faster?"
Case 1 is faster than Case 2: not in runtime, but definitely in reading time, understanding time, debugging time, and maintenance time.
"I would like to know whether there is a difference between following cases"
Yes, there is a major difference: Case 1 is much clearer, which in turn leads to fewer bugs and makes code easier to understand and debug.

Melden Sie sich an, um zu kommentieren.

Akzeptierte Antwort

Guillaume
Guillaume am 2 Jul. 2019
No, there is no difference between the cases. More importantly, even if there was, you shouldn't care until you've proven that the operations are a bottleneck.
If you haven't proven that the operations are a bottle neck (by using the profiler), then you should care about clarity, and for that reason, you should prefer case 1 over case 2. As for the other two cases, unless nVar and v1 are going to be reused later on, I'd prefer case 4 as there's little point in creating temporary variables that are only used once.
But again, considerations about speed shouldn't even be on your radar at this point.

Weitere Antworten (1)

Jan
Jan am 2 Jul. 2019
Bearbeitet: Jan am 2 Jul. 2019
%Case 1
X = 1;
Y = X + 4;
Z = X + Y;
%Case 2
X = 1; Y = X + 4; Z = X + Y;
The documentation of Matlab stated, that the JIT acceleration works only, if you write one statement per line, because it needs the power to re-order the commands. In your case there is no difference, but in general 1 statement per line is preferred and, by the way, easier to read.
The JIT is not fully documented and subject to changes between Matlab versions. But I can imagine, that this feature is still valid.
% Case 3
v1 = k1{t};
nVar = size(v1, 2);
CP = randsample(nVar-1, 2);
% Case 4
CP = randsample(size(k1{t}, 2)-1, 2);
This is a question of taste. While the runtime is identical, another point gets important: The total time for solviong a problem is built by:
T_total = T_planning + T_programming + T_documentation + T_debugging + T_runtime
Optimizing such tiny pieces of code for the runtime can increase the timings for debugging and documenting. So if the code runs a microsecond faster and is called 1 million times, you save a full second. If you have a typo, which is concealed in the dense code of Case 4, but would be found directly in Case 3, you might save 1 hour of debug time.
"Premature optimization" is a bad programming practice. You loose more than you win. See https://en.wikipedia.org/wiki/Anti-pattern

Tags

Produkte


Version

R2019a

Community Treasure Hunt

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

Start Hunting!

Translated by