Buffer Allocation - Revision history

Logmanoriginal: Rewrite and extend

2019-08-30T09:50:57Z

Rewrite and extend

Michael_Aivaliotis at 05:55, 26 May 2008

2008-05-26T05:55:25Z

← Older revision		Revision as of 05:55, 26 May 2008
Line 17:		Line 17:
	* [http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/vi_memory_usage/ LabVIEW 8.5 Help>>VI Memory Usage]		* [http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/vi_memory_usage/ LabVIEW 8.5 Help>>VI Memory Usage]

	[[~~Special~~:~~Uncategorizedpages~~]]		[[category:memory management]]

Jim Kring: Added External Links and link to VI Memory Usage page of LabVIEW help

2008-03-25T22:04:20Z

Added External Links and link to VI Memory Usage page of LabVIEW help

← Older revision		Revision as of 22:04, 25 March 2008
Line 13:		Line 13:

	And don't call them "copy dots." :-)		And don't call them "copy dots." :-)

			== External Links ==
			* [http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/vi_memory_usage/ LabVIEW 8.5 Help>>VI Memory Usage]

	[[Special:Uncategorizedpages]]		[[Special:Uncategorizedpages]]

V-davsny@microsoft.com at 19:25, 25 March 2008

2008-03-25T19:25:55Z

← Older revision		Revision as of 19:25, 25 March 2008
Line 6:		Line 6:

	Now, take a look at this diagram. Notice the buffer allocations:<br />		Now, take a look at this diagram. Notice the buffer allocations:<br />
	[[Image:~~Example~~.~~jpg~~]]		[[Image:subarraycopydots.png]]

	The "Split 1D Array" node has two output buffer allocations. A lot of people would think, "Look at those copy dots. That means LabVIEW is making two new arrays, one for the first part of the array, and one for the second part of the array." Not true. The buffer allocations are for the subarrays. Remember I said that a subarray records a reference to the array, a starting index, a length and a stride. Those four items of data have to be stored somewhere. The buffer allocation is the allocation to store those four items. It is not a copy of the entire array. The output of the Build Array, on the other hand, is a full array allocation.		The "Split 1D Array" node has two output buffer allocations. A lot of people would think, "Look at those copy dots. That means LabVIEW is making two new arrays, one for the first part of the array, and one for the second part of the array." Not true. The buffer allocations are for the subarrays. Remember I said that a subarray records a reference to the array, a starting index, a length and a stride. Those four items of data have to be stored somewhere. The buffer allocation is the allocation to store those four items. It is not a copy of the entire array. The output of the Build Array, on the other hand, is a full array allocation.

V-davsny@microsoft.com: Tips for interpreting buffer allocation dots

2008-03-25T19:22:04Z

Tips for interpreting buffer allocation dots

New page

Note: The following was copied from a [http://forums.lavag.org/Another-reason-why-copy-dots-is-a-bad-name-for-buffer-allocations-t10406.html#entry43277|forum post] by Aristos Queue.

There is a tool in LabVIEW called the "Show Buffer Allocations" tool. You can find it in a VI's menu at Tools>>Profile>>Show Buffer Allocations.... It is a useful tool for doing memory optimizations because it shows little dots every place that the LabVIEW compiler made a buffer allocation. Some people call these "copy dots" because people *think* these indicate where LabVIEW is making a copy of the data. About 90% of the time, that is accurate. But there are some cases where a "buffer allocation" and a "copy" are not the same thing at all. Today I want to mention one that I haven't posted before.

When using arrays, one of the major times when buffer allocations are of interest to programmers, not all buffer allocations are copy dots. Whenever possible, LabVIEW will do an operation on an array by creating a "subarray". If you pay close attention to the Context Help window, you'll sometimes see wires that are of "subarray" type. A subarray is simply a reference to another array, storing an index into that array and a stride and a length. This is a very efficient way to do some pretty complex operations without actually making new arrays, such as decimate array, split array, and reverse array. That last one returns an index to the last element of the array and a stride length of -1. The return of a subarray is only possible when LabVIEW knows that no other operation is going to be modifying the value of the array, so it is safe for the reference to the array in memory to be shared.

Now, take a look at this diagram. Notice the buffer allocations:<br />
[[Image:Example.jpg]]

The "Split 1D Array" node has two output buffer allocations. A lot of people would think, "Look at those copy dots. That means LabVIEW is making two new arrays, one for the first part of the array, and one for the second part of the array." Not true. The buffer allocations are *for the subarrays*. Remember I said that a subarray records a reference to the array, a starting index, a length and a stride. Those four items of data have to be stored somewhere. The buffer allocation is the allocation to store those four items. It is not a copy of the entire array. The output of the Build Array, on the other hand, is a full array allocation.

To see what is being allocated at any given buffer allocation, look at the type of the wire.

And don't call them "copy dots." :-)

[[Special:Uncategorizedpages]]