Re: creating an array by inserting 51 set of different values - labview

Constant folding existed for a long time, but it got enhanced in recent versions to include more complex structures.  A relatively new feature is the ability to show the constant folding graphically as in my image. (off by default).
 
The memory impact is often not as big as you might expect because there is also compression. How do you explain the following variation?
 
<img src="http://forums.ni.com/attachments/ni/170/289223/1/foldedmemory.png"> Message Edited by altenbach on 12-08-2007 10:06 AM


foldedmemory.png:
http://forums.ni.com/attachments/ni/...ldedmemory.png

First&nbsp;you are not bothering...!
It is not required.. if you don't do it manualy, Labview will do it for you... and it will display a small red dot at the input of multiplier.. try it.
It is a good programming practice , although at this example it has no difference ...
&nbsp;
&nbsp;
PS: Hey now i can rate an answer :smileyhappy:

It is not really required, but it is slightly&nbsp;more efficient. You can leave it out and it will coerce at the multiply primitive automatically. The difference is minimal in this case.
The red coercion dot will tell you that a coercion takes place. If you are dealing with huge data structures and are worried about performance it is always worth to go over the code, look for coercions, and eliminate them if possible. Often they arise from careless programming.
Look at the following variation where the difference&nbsp;would be&nbsp;more dramatic. If you don't convert inside the loop, it will generate a I32 array which it will need to convert to a DBL array at the multiply node. If you convert inside the loop, you save the&nbsp;memory allocation of the I32 array.
<img src="http://forums.ni.com/attachments/ni/170/289231/1/coerceIt.png">
Again, an array with 50 elements is peanuts on any scale, but if you stop and think for a second whenever you see a red dot, it will be a useful habit&nbsp;once you start to deal with huge projects.
&nbsp;
&nbsp;Message Edited by altenbach on 12-08-2007 11:56 AM


coerceIt.png:
http://forums.ni.com/attachments/ni/...1/coerceIt.png

Pnt wrote:

...&nbsp;although at this example it has no difference ...


No&nbsp;significant or useful&nbsp;difference!
&nbsp;
Actually, there seems to be a very small penalty for inplicit coercion versus explicit conversion. Here's a link to&nbsp;benchmark where we discussed this a while ago:
&nbsp;
<a href="http://forums.ni.com/ni/board/message?board.id=170&amp;view=by_date_ascending&amp;message.id=236938#M236938" target="_blank">http://forums.ni.com/ni/board/message?board.id=170&amp;view=by_date_ascending&amp;message.id=236938#M236938</a>
My own and Ben's testing in the past consistently show the same result. It is somewhat surprising, because you would think that the compiler could generate exactly the same code for both cases, but there seems to be a subtle difference and explicit always wins by a hair.

Pnt wrote:

if&nbsp;I rate an answer no stars apear on the left .. !?


Since the board upgrade a few weeks ago, there is a delay before stars appear. See:
&nbsp;
<a href="forums.ni.com/ni/board/message?board.id=130&amp;thread.id=3890&amp;jump=true" target="_blank">forums.ni.com/ni/board/message?board.id=130&amp;thread.id=3890&amp;jump=true</a>
&nbsp;
&nbsp;

nrp wrote:Now, your reply with the large loop count intrigues me! How is the VI compressed? If I tinker around with the loop mathematics, i.e. putting in weird functions like sin(x)/x it does not seem to have any effect. (Although I did manage to get LV 8.5 to crash on me once after taking quite a long time to save, saying out of memory, so maybe I fooled it once?)I give up, what is going on???


LOL, Frankly I don't know any of the details, just base my statements on observations I made over the years. A couple of version ago, VIs became significantly smaller on disk, so it seems some of the contents are compressed to get rid of the hot air.
&nbsp;
In this particular case, I don't think the contents of the folded array are stored on disk, but maybe the loop is precalculated when the VI loads instead of when it is run. (You migh say that storing the instructions to create the folded array is probably one of the most efficient special purpose compression algorithms known to man. "Uncompressing" during loading of the VI&nbsp;just executes the loop code, right?).
&nbsp;
If you would turn one of the loop input diagram constants&nbsp;into a control, you'll see that the memory footprint will be smaller by the size of the folded array. The memory buffer for the folded array is not re-used.
The LabVIEW developers have quite a few&nbsp;rabbits in their magic hat and some of these things change between versions. Let's just be grateful that it works as well as it does.