Show buffer allocation pop-up detail

[Matthew_Williams]

A pop-up that appears when a user hovers over a buffer allocation dot would be very useful.

Data to display:

1) size of allocation in bytes

2) expected longevity (freed when vi quits vs. USR)

3) frequency of allocation (once at first run, each loop, etc.)

I know some of the data can only be a best guess but whatever additional data we can get

will be an improvement, especially when dealing with large data sets.

Thanks.

Matt

[Broken_Arrow]

Easier-to-see dots would also be nice - maybe red, and/or larger. Just IMO due to my aging eyes.

[RavensFan]

What version of LabVIEW are you using?  I know in most recent versions  (starting LV 8.0??) , the coercion dots are red by default, and are also changeable within the Options/Environment dialog box.  In LV 7.1, the coercion dots are grey by default, but that is also changeable in the Options/Color dialog box.  But in either case, I don't think you can change the size.

[JackDunaway]

Ravens, not coercion dots... black buffer allocation rectangles when you go to Tools>Profile>Show Buffer Allocations.

Message Edited by JackDunaway (mechelecengr) on 09-21-2009 12:41 PM

[RavensFan]

You're right.  My mind must not have been fully awake yet when I read that.  I agree, those buffer allocation dots are difficult to see and have kudoed the idea.

[AristosQueue (NI)]

> Data to display:

> 1) size of allocation in bytes

Do you want static top-level allocation or complete allocation of the data inside that buffer? In other words, suppose you have a cluster of a double and a string, and the double has value 3.4 and the string has value "ABC". The top-level size on a 32-bit machine would be 12 (8 bytes for double and 4 bytes for  the string handle) and wouldn't change no matter what the value. The full data size would be 23, accounting for the string pointer and the 4 byte length field and the actual ABC text. 

> 2) expected longevity (freed when vi quits vs. USR)

All buffer allocations have the same longevity: As long as the VI stays in memory. None of them are freed when the VI stops running.

> 3) frequency of allocation (once at first run, each loop, etc.)

All buffer allocations have the same allocation: When the VI comes into memory. 

[AristosQueue (NI)]

> None of them are freed when the VI stops running.

Except when a user uses the explicit garbage collection primitive whose name I forget. I've never used it. 

[Matthew_Williams]

>> Data to display:

>> 1) size of allocation in bytes

>Do you want static top-level allocation or complete allocation of the data inside that >buffer? In other words, suppose you have a cluster of a double and a string, and >the double has value 3.4 and the string has value "ABC". The top-level size on a >32-bit machine would be 12 (8 bytes for double and 4 bytes for  the string handle) >and wouldn't change no matter what the value. The full data size would be 23, >accounting for the string pointer and the 4 byte length field and the actual ABC >text. 

An indication of 'data' space and 'overhead' space would be nice, but total memory consumption would be fine, too.   Another option would be to just add a total memory consumed (for the probed item) indication to a probe.  Might be easier to implement, and would provide more information as you could watch memory consumption increase as the program runs.

[AristosQueue (NI)]

Memory consumed can be tracked using Tools >> Profile >> Performance and Memory... tool. I really can't imagine any value to probing this for a particular terminal. It would be easy enough for someone to write, but my instinct says that it would be so rarely used that it wouldn't be worth R&D's time to put it together. If you want to write such a custom probe, you can, using the information in the external code manual (see LV's help files) and the VariantType library for traversing types located in <LabVIEW>\vi.lib\Utility\VariantDataType