You have a requirement to build an array of random U8 numerical values using a loop. Put the following methods and loop types in order of performance (quickest to slowest)?
a) For loop using "auto indexing"b) For loop using "build array" and a Shift Registerc) While loop using "auto indexing"d) While loop using "build array" and a Shift Register
A C B D
A, C, B, D
can it be C A D B ??????
No, A is definitely the most efficient. The reason is because a FOR loop has a fixed number of iterations. So the Autoindex tunnel has a preallocated array.
The While Loop with the autoindex is next because of how the compiler incrementally preallocates more memory for the output tunnel. Put simply, it doubles the memory when the allocated memory is used up.
B and D I would say are about the same since the Build Array forces a memory reallocation each time it is ran.
So I had a go and got the following timings for making an array of 100,000 U8 numbers (in seconds)
c) 0.015 (which is pretty quick, I thought this would have taken longer)
I guess the difference between b&d is code I added to decide when to stop the while loop?
I just did a benchmark of generating 1M random doubles for each method and averaged over 100 iterations. I got the following average times:
FOR Autoindexing: 22.52ms
While Autoindexing: 25.17ms
FOR Shift Register: 122.82ms
While Shift Register: 280.99ms
NOTE: LabVIEW 2016 32-bit, made sure debugging was turned off
I can’t offer a detailed explanation. But my assumption was the same: A For loop should be faster than a while loop (more work to do with comparisons, open end till condition) and auto index should be faster than build function (build function seems to me a more universal and complex function). Second reason seems more significant than first reason. So A-C-B-D
my gut feeling says A, C, B+D
i know that A must be the fastest, because the array will be allacoted in the proper size since it is known how big it must be,
B second because i guess there will be some fancy optimization to allocate array ressources efficiently.
B+D should be somewhat equal, since in each step the new array has to be allocated.
EDIT: oh nice .. mostly right, although i am now curious how crossrulez' B and D differ by a factor of 2, i would have guessed timsrize's result to be the one. any explanations for the difference?
Following the techniques taught in Core l and Core ll, I would say the correct answer is:
A, C, B, D;
See you soon.
I agree ACBD but why would it matter if I am only communicating with slow test equipment (measured in mS latencies) and not making a replacement for Quake, Half-Life or any modern OpenGL games? Wouldn't the best method for the functionality and readability of the VI more important than saving a few uS in execution time?
In this case, A is both the easiest to read and the most performant. I have found that the two go together 90% of the time.
But general performance is important. Do we really need to tweak every possible us out of an application. 99.9% of the time, no. But it is still best to keep these things in mind. As an anecdote, I once inherited a test system. In that code was a VI that calculated a CRC. It was HORRIBLY written, but somehow worked. One of the first things I did was rewrite the VI. Yes, the VI was a lot easier to read afterward. But just as important was that it was faster. We are talking possibly a ms per call, but this VI was called enough that that change alone saved nearly half an hour in test time. I had similar updates throughout that code base and managed to cut about an hour off of a 4 hour test. Manufacturing was quite happy with that result.
I agree 100% there will be a function that will need all the speed you can get out of the CPU such as deeply-nested loops collecting/parsing/processing data from test equipment or UUT (baseband captures, FPGA, CPLD to name a few) I have run in to several of these over the years.
So the simplest, lightest will *always* be the best (which is A in this case).
A - C - B - D
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.