Labview and memory handling for arrays

[Hansel]

Hi,

I'm currently building a vi with sub-vi's to display large data
array's in graphs. (large : >20mB of I16)

I'm trying to store one of these data array's in the computer mem and
sometimes select a very small porpotion of this array for displaying
since the waveform graph is very sluggish with large array's.

Now the problem:
Labview is not very friendly with data arrays overall (it always keeps
numurous copies of the data) but this becomes noticable with this size
of data array's.

Is there any way to get labview to store this array at a fixed
position in the mem after reading it from disk without generating
copies of this array?

And is there any way to access this mem-region directly (very usefull
for selecting
a small propaortion of this array)


Any help will be welcome.

Hansel

[CraigGraham]

Hansel wrote in message
news:0k37usorhds98t8umbnu0ct7sn72l0f85s@4ax.com...

> And is there any way to access this mem-region directly (very usefull
> for selecting a small propaortion of this array)

Allocate the arrays at the start of the program using "Initialise Array" and
use "Replace Array Element" and "Array Subset" to read and write to the
array. Make sure you only add data using "Replace Array Element"- any time
you use "Build Array" or you create the array by autoindexing as the data
comes out of a loop you are reallocating the memory and copying all the
data, leading to performance hits and memory fragmentation. As long as
you're not destroying and recreating the array, operations are pretty fast-
and if you pass it down to a sub-vi for man
ipulation, as long as you follow
the same rules then the array is passed by reference, again speeding things
up.

[Thomas Ludwig]

Hansel wrote:

>
> Is there any way to get labview to store this array at a fixed
> position in the mem after reading it from disk without generating
> copies of this array?

No. LabVIEW _should_ do this whenever it is possible. LabVIEW can't do
this, when - for example - you modify an array and use the modified as
well as the unmodified version of the array. LabVIEW is also forced to
copy an array that is passed to a reentrant sub vi. Sometimes (actually
quite often!) LabVIEW copies arrays without any reason.

LabVIEW 5.0 had a buggy memory management and nearly always made copies.
So if you are using 5.0, you should consider an update to 5.1. Don't
update to 6i, it is as buggy as 5.0.

You might as well ask NI's support, but for me they turned out to be not
very
helpful (I had an example in 5.0 for solaris that clearly should
_not_ copy data passed to a subvi but actually copied data for every
subvi call. Although this was a wellknown bug (not to me...) they
answered: ' This is the expected behaviour on a sun'.)

To sum it up: LabVIEW is bad at handling large amounts of data when your
task is so complex that you need subvis - no matter what NI says about it.

Thomas

PS: I was asking pretty much the same question a few month ago in this
group. This is where I learned about the bug in 5.0, not from NI. You
might want to look the thread up in deja.
--
Thomas Ludwig
Institute of Mineralogy
University of Heidelberg, Germany

[CraigGraham]

Thomas Ludwig wrote in message
news:39E44C1C.DE53C311@gmx.de...

> To sum it up: LabVIEW is bad at handling large amounts of data when your
> task is so complex that you need subvis - no matter what NI says about it.

This may be rather an unfair overgeneralisation. Perhaps you should have
said "The SUN version of LabVIEW" there.

It may be that each VI in Labview is a different child process of the
Labview core, and that under Windows there are fewer constraints on passing
ownership of memory between processes than there are on Unix.

[Hansel]

On Wed, 11 Oct 2000 13:16:45 +0200, Thomas Ludwig
wrote:

>Hansel wrote:
>
>>
>> Is there any way to get labview to store this array at a fixed
>> position in the mem after reading it from disk without generating
>> copies of this array?
>
>No. LabVIEW _should_ do this whenever it is possible. LabVIEW can't do
>this, when - for example - you modify an array and use the modified as
>well as the unmodified version of the array. LabVIEW is also forced to
>copy an array that is passed to a reentrant sub vi. Sometimes (actually
>quite often!) LabVIEW copies arrays without any reason.
>
>LabVIEW 5.0 had a buggy memory management and nearly always made copies.
>So if you are using 5.0, you should consider an update to 5.1. Don't
>update to 6i, it is as buggy as 5.0.
>
>You might as well ask NI's support, but for me they turned out to be not
>very helpful (I had an example in 5.0 for solaris that clearly should
>_not_ copy data passed to a subvi but actually copied data for every
>subvi call. Although this was a wellknown bug (not to me...) they
>answered: ' This is the expected behaviour on a sun'.)
>
>To sum it up: LabVIEW is bad at handling large amounts of data when your
>task is so complex that you need subvis - no matter what NI says about it.
>
>Thomas
>
>PS: I was asking pretty much the same question a few month ago in this
>group. This is where I learned about the bug in 5.0, not from NI. You
>might want to look the thread up in deja.


Thanx for the Info.

I am using Labview 5.1 and just as you said, labview is making copies
without reason. Seem's like 5.1 has the same bug as 5.0.

I've also asked NI for support, but even with the vi-program mailed to
them they couldn't understand why Labview uses so much memory.

I've found one solution for reducing the mem-usage as much as
possible:
By giving each sub-vi a 'real' call followed by a dummy-call with
no-data attachted to it, the mem used by this sub-vi (which actally
stays in mem) is cleared. By doing this I have reduced the maximum
mem-usage to a foctor 2 of the real data-set, where the actual copying
takes places at the start, so the program starts slowly but then only
uses about 1.5 times the array-size.

I'ts not what I hoped for, but it will have to do. Guess my computer
could use another 128 MB Ram.


Hansel

[Greg_McKaskle2]

It sounds like you have discovered one of the ways to influence the LV
algorithms for data management. For other information, you may want to
look at chapter 27 I believe. It is the Performance chapter. There are
also issues of LTR, application notes, and quite a few emails on
info-labview about this. As for the bug in LV5, it meant that, more
often than necessary, subVIs would make data copies. This was not the
case in earlier versions, nor in LV6i. At least not to my knowledge.

One of the things that one gains when using LV is the freedom from data
allocation and data management. The downside of this is that this
automatic memory management may not be as clever as you are. On the
otherhand, many times there are perfectly good reasons for the data
copies, they just aren't obvious. As for asking NI support for help.
They do a great job, but these things are truly complicated, and this is
sometimes beyond their training. As I said, there is information
available, or if you ask the questions here, I'll do what I can to
answer them.

Greg McKaskle

Hansel wrote:
>
> On Wed, 11 Oct 2000 13:16:45 +0200, Thomas Ludwig
> wrote:
>
> >Hansel wrote:
> >
> >>
> >> Is there any way to get labview to store this array at a fixed
> >> position in the mem after reading it from disk without generating
> >> copies of this array?
> >
> >No. LabVIEW _should_ do this whenever it is possible. LabVIEW can't do
> >this, when - for example - you modify an array and use the modified as
> >well as the unmodified version of the array. LabVIEW is also forced to
> >copy an array that is passed to a reentrant sub vi. Sometimes (actually
> >quite often!) LabVIEW copies arrays without any reason.
> >
> >LabVIEW 5.0 had a buggy memory management and nearly always made copies.
> >So if you are using 5.0, you should consider an update to 5.1. Don't
> >update to 6i, it is as buggy as 5.0.
> >
> >You might as well ask NI's support, but for me they turned out to be not
> >very helpful (I had an example in 5.0 for solaris that clearly should
> >_not_ copy data passed to a subvi but actually copied data for every
> >subvi call. Although this was a wellknown bug (not to me...) they
> >answered: ' This is the expected behaviour on a sun'.)
> >
> >To sum it up: LabVIEW is bad at handling large amounts of data when your
> >task is so complex that you need subvis - no matter what NI says about it.
> >
> >Thomas
> >
> >PS: I was asking pretty much the same question a few month ago in this
> >group. This is where I learned about the bug in 5.0, not from NI. You
> >might want to look the thread up in deja.
>
> Thanx for the Info.
>
> I am using Labview 5.1 and just as you said, labview is making copies
> without reason. Seem's like 5.1 has the same bug as 5.0.
>
> I've also asked NI for support, but even with the vi-program mailed to
> them they couldn't understand why Labview uses so much memory.
>
> I've found one solution for reducing the mem-usage as much as
> possible:
> By giving each sub-vi a 'real' call followed by a dummy-call with
> no-data attachted to it, the mem used by this sub-vi (which actally
> stays in mem) is cleared. By doing this I have reduced the maximum
> mem-usage to a foctor 2 of the real data-set, where the actual copying
> takes places at the start, so the program starts slowly but then only
> uses about 1.5 times the array-size.
>
> I'ts not what I hoped for, but it will have to do. Guess my computer
> could use another 128 MB Ram.
>
> Hansel
>