Why get arrays copied when a subvi is called?

[Thomas Ludwig]

Labview 5.0.1, Solaris 8 on a Ultrasparc 5

Imagine two very simple vis:

1) subtest.vi: Has a control and an indicator, both 1D-arrays of 'DBL'. The
control is wired directly to the indicator, both arrays are empty, the
vi is
saved and the front panel is NOT open.
2) memtest.vi: Has a 'FOR' loop with a 'DBL' constant in it which is connected
to the border of the loop, indexing is enabled. 100000 is wired to 'N'. the
output of this loop (an array of 100000 'DBL' values = 800kB) is wired to
'array size' which again is wired to an 'I32' indicator.

If you run 'memtest.vi', the profiler will report approx. 800kB of
memory used
by memtest.vi. So far, so good. Now, if I insert 'subtest.vi' between
the loop
and 'a
rray size' (Again: the front panel of subtest.vi is NOT open), the
profiler will report approx. 1600kB of memory and the timing statistics clearly
show, the the array gets copied.

What's going on here? The 'G Reference' clearly states, that under these
circumstances the array should not be copied.

NI support says:

"According to R&D, this is the expected behavior on a Sun."

and

"The G Reference Manual was written with the
Mac OS and Windows OS as references."

I can't believe it. This makes Labview useless for me.

Has anybody else experienced this? Any hints, ideas ... are welcome.

TIA
Thomas
--
Thomas Ludwig
Institute of Mineralogy
University of Heidelberg, Germany

[Kevin_work]

Thomas,
I just tried this on an Ultra10, Solaris7 with LabVIEW 5.1
I do not see this behavior. I think I re-created it correctly, but you can
send me a copy of your VIs if you want.

I will say that 5.0.1 had some memeory problems and I would suggest that
you upgrade to 5.1.x as a minimum. There is an update from 5.0.1 to 5.0.1f1
which is free on NIs ftp site. I am a little suprised they did not tell you.
This update helps with some of the inplaceness (IE without copying)
array operations.

I am not sure whay you say this makes Labview useless. I have used it on Sun
machines since
Version 3.x. and it works fine. There have been a few instances where I ran into
problems but
usually I could change the code to be more efficient.

Let me know if you need more help.
Kevin Kent


Thomas Ludwig wrote:

> Labview 5.0.1, Solaris 8 on a Ultrasparc 5
>
> Imagine two very simple vis:
>
> 1) subtest.vi: Has a control and an indicator, both 1D-arrays of 'DBL'. The
> control is wired directly to the indicator, both arrays are empty, the
> vi is
> saved and the front panel is NOT open.
> 2) memtest.vi: Has a 'FOR' loop with a 'DBL' constant in it which is connected
> to the border of the loop, indexing is enabled. 100000 is wired to 'N'. the
> output of this loop (an array of 100000 'DBL' values = 800kB) is wired to
> 'array size' which again is wired to an 'I32' indicator.
>
> If you run 'memtest.vi', the profiler will report approx. 800kB of
> memory used
> by memtest.vi. So far, so good. Now, if I insert 'subtest.vi' between
> the loop
> and 'array size' (Again: the front panel of subtest.vi is NOT open), the
> profiler will report approx. 1600kB of memory and the timing statistics clearly
> show, the the array gets copied.
>
> What's going on here? The 'G Reference' clearly states, that under these
> circumstances the array should not be copied.
>
> NI support says:
>
> "According to R&D, this is the expected behavior on a Sun."
>
> and
>
> "The G Reference Manual was written with the
> Mac OS and Windows OS as references."
>
> I can't believe it. This makes Labview useless for me.
>
> Has anybody else experienced this? Any hints, ideas ... are welcome.
>
> TIA
> Thomas
> --
> Thomas Ludwig
> Institute of Mineralogy
> University of Heidelberg, Germany

[Thomas Ludwig]

"Kevin B. Kent" wrote:


> Thomas,
> I just tried this on an Ultra10, Solaris7 with LabVIEW 5.1
> I do not see this behavior. I think I re-created it correctly, but you can
> send me a copy of your VIs if you want.

Thanks for trying.

> I will say that 5.0.1 had some memeory problems and I would suggest that
> you upgrade to 5.1.x as a minimum. There is an update from 5.0.1 to 5.0.1f1
> which is free on NIs ftp site. I am a little suprised they did not tell you.
> This update helps with some of the inplaceness (IE without copying)
> array operations.

I know the f1 update. I can't use it because it has a bug under CDE (You
can't make any labview window _smaller_). I somehow expected to hear
'It's a bug. Go for 5.1.x'. I certainly was not expecting to hear
'This
is expected...'.
>
> I am not sure whay you say this makes Labview useless. I have used it on Sun
> machines since
> Version 3.x. and it works fine.

Well, I need to operate on large arrays e.g. every 10 ms. If the array
is large enough and/or the machine is slow enough (I've been working on
an SS10/50MP before), copying arrays slows things down considerably.


Thanks for yor reply.

--
Thomas Ludwig
Institute of Mineralogy
University of Heidelberg, Germany

[David Thomson]

Thomas Ludwig wrote:
>
> Labview 5.0.1, Solaris 8 on a Ultrasparc 5
>
> Imagine two very simple vis:...
>
Thomas,
This sub-vi inplaceness problem was a very definite problem in one
version of LV 5.x (5.0 I think), at least on Windows. Upgrading to
5.1.1 definitely resolved it for me under WinNT and W98. I would guess
that would fix it on the Sun as well.

Regards,
Dave Thomson

-------------------------------------------------------------
David Thomson 303-499-1973 (voice and fax)
Original Code Consulting dthomson@originalcode.com
www.originalcode.com
National Instruments Alliance Program Member
-------------------------------------------------------------
Research Scientist 303-497-3
470 (voice)
NOAA Aeronomy Laboratory 303-497-5373 (fax)
Boulder, Colorado dthomson@al.noaa.gov
-------------------------------------------------------------

[Thomas Ludwig]

David Thomson wrote:

> This sub-vi inplaceness problem was a very definite problem in one
> version of LV 5.x (5.0 I think), at least on Windows. Upgrading to
> 5.1.1 definitely resolved it for me under WinNT and W98. I would guess
> that would fix it on the Sun as well.


Dave,

thanks for that answer. Hopefully NI will find that answer, too.

Now I'll have to see the boss and ask for some money.
[We bought a computer in 1985! Why do you need another one?? ;-)]

Regards,

Thomas
--
Thomas Ludwig
Institute of Mineralogy
University of Heidelberg, Germany

[Thomas Ludwig]

The problem is a bug in Labview 5.0.x. Today I received the 5.1 upgrade
and now it behaves as expected.

NI still was not able to tell me that it's a bug in 5.0 and that the
problem is solved in 5.1...

Thanks again to Kevin and David.

Regards,
Thomas
--
Thomas Ludwig
Institute of Mineralogy
University of Heidelberg, Germany

[Craig Prater]

This is still "broken" in Version 6i. I'm not sure it's easy to fix. If you make a subVI to perform a data manipulation and pass it back to the calling vi, you have to create a control and indicator to read in and send out the data. I think the issue is that the control and indicator has to be able to display different data. I think this requires having a separate buffer for both the indicator and the control. This issue is forcing me to put my big array manipulation into my main vi to conserve on memory.

Craig

[CraigGraham]

How are you testing this? As I understand it, simply passing a big array to
a subVI, manipulating it using "replace element" and passing it back out
shouldn't cause spurious copies to be made if;

1) The VI's panel is not at all open (including open but minimised)
2) The VI does not have any unsaved changes

2) may actually not be related to this- I remember it's a "gotcha" along
similar lines but I can't remember exactly what the problem of having an
unsaved VI in memory is. If the front panel is open, then as you say two
different copies of the array have to exist in the controls, but this isn't
the case if the panel is closed- if you have your top level VI running and
you open the panel of the subVI *after* an array operation, you should not
see t
he arrays in the control and indicator- they'll just be set to default.
Only when the VI is called with the panel open is the data copied for
display purposes.

Craig Prater wrote in message
news:101-506500000005000000801A0000-982303670000@quiq.com...
> This is still "broken" in Version 6i. I'm not sure it's easy to fix.
> If you make a subVI to perform a data manipulation and pass it back to
> the calling vi, you have to create a control and indicator to read in
> and send out the data. I think the issue is that the control and
> indicator has to be able to display different data. I think this
> requires having a separate buffer for both the indicator and the
> control. This issue is forcing me to put my big array manipulation
> into my main vi to conserve on memory.
>
> Craig

[alkazaa]

Also keep in mind that the subVI must not use local variables. If it does, it's
front panel IS ALWAYS IN MEMORY causing duplicates of th front panels' elements

Craig Graham schrieb:

> How are you testing this? As I understand it, simply passing a big array to
> a subVI, manipulating it using "replace element" and passing it back out
> shouldn't cause spurious copies to be made if;
>
> 1) The VI's panel is not at all open (including open but minimised)
> 2) The VI does not have any unsaved changes
>
> 2) may actually not be related to this- I remember it's a "gotcha" along

--
Dr. Franz Josef Ahlers
Section Semiconductor Devices
Physikalisch-Technische Bundesanstalt
Bundesallee 100
D-38116 Braunschweig
phone: (+49) 531 592 2419
fax:
(+49) 531 592 2405

[Greg_McKaskle2]

> Also keep in mind that the subVI must not use local variables. If it does, it's
> front panel IS ALWAYS IN MEMORY causing duplicates of th front panels' elements
>

Actually, local variables do not cause the panel to be in memory, but
property nodes, or attribute nodes as they used to be called, will cause
the panel to stay in memory. Local variable reads will allocate their
own storage, and creating duplicate arrays to write back to a control
local almost certainly indicates a VI that is using controls like
variables rather than using dataflow.

Greg McKaskle