> If you compare Mike Porter's solution, you'll notice that it is at least 10x
> faster than the other versions discussed here. Apparently, growing an array
> (to an initially undetermined size) at the loop boundary is MUCH cheaper
> than doing the same with the built array tool as in B&C Duffey's version. I
> was not fully aware of that. I wonder if something could be more
> optimized...
>
....
> register with a worst-case (=size of input) array, use "replace array
> element" instead of "built array" inside the case, and, after the loop, you
> just strip it back to the final size with "array subset".
> This pre-allocates the array in one step and throws away the unused tail
> later.
>
> The speed difference is truly amazing! Could anyone c
omment on this...
I did a presentation at NIWeek that contains this exact
example along with other common performance problems.
Its examples should be on the ni.com web site with the
NIWeek files. This information is also in the user
manual in the performance chapter, used to be chapter 27.
As to why it takes longer to grow an array with build-array,
it comes down to the memory management that this causes.
An auto-indexing tunnel on a loop can figure out exactly how
many iterations a for loop will run, and it does some
estimates on while loops. When you place a build-array
inside of a loop and add an element, LV does them one at
a time. Someday, maybe LV will rewrite your diagram in an
equivalent, but more efficient manner, but for now, this
is something that is left to the diagram writer.
By the way, this was much slower before LV5. LV5 improved
inplaceness for build-array and some other nodes, and sped up
the build-array in a loop case by aobut 50-100X. This is still
slow co
mpared to the other techniques though.
Greg McKaskle