GOOP woes, memory related

[Joseph Oravec]

Hi I've got some GOOP woes, two questions

1 - Has anybody used GOOP 2.0 listed on www.endevo.com and know if its a
good update? I am pretty dissatisfied with the $45 charge. Sure they deserve
some money, but I really dont know if the update will fix my problems.

2 - More importantly, I had a program which seemed to be leaking memory. I
haven't attached the VI but I could. Its just such a self-explanatory
program. My setup is a P3-500, Windows XP, Labview 6.1, and I think 400 meg
RAM. I am using GOOP from www.endevo.com

I made two cases. The first uses a GOOP object and stores a 1-D array of
44.1 kHz of some random length between 30 and 40 seconds. The second uses a
GOOP object and with a 2-D array to store 5 or 6 copies of the same
waveform. Each program has a parallel reader loop to read the update the
front-panel just so this simulates a real system. I ran the store function
in a for-loop 100 times in order to simulate heavy usage. Although I didn't
notice problems from create/delete specifically, I also ran the entire
simulation in a for-loop 10 times.

In my testing, the 1-D case seems to be ok: the windowsXP perfmon shows the
total system memory allocation going from 150meg to 330meg while the VI is
running which is a lot, but reasonable given labview overhead. However in
the 2-D case, the windowsXP perfmon shows the total system memory allocation
constantly increasing. Perhaps there is some major difference? I didn't see
any references that needed closing.

I noticed this originally on the Waveform type, if an array of waveforms is
stored in a GOOP object under the same conditions it will allocate excessive
amounts of memory so perhaps somebody has noticed the same problem? How can
this be fixed, or am I doing something totally wrong?

Please drop me an email or post to the group with comments, this is a
total-showstopper for me using GOOP right now! Very confused, I didn't see
an email-support link for the maintainers, and since the VIs are password
locked I couldnt track down the problem myself

-joey

[Mattias_Ericsson]

Hi Joey!

1)
GOOP Wizard 2.0 adds a lot of edit functionallity that was missing in Wizard 1.0 such as:
*Renaming class
*Cloning class
*Automatic icon handling (you do not have to manually edit every VI icon anymore!)
*Rename method
*Clone method
*Delete method
*Rename class
*Mass compile class

Other features are that you now can store the class as regular VIs and is not forced to use LLB. It is easy to convert a LLB-class to regular VIs and vice verse.

Class icons can be edited at anytime. For instance you can change header, colors of the class automatically and this saves time, a lot of time. Documentation is also improved.

It uses the same GOOP Class template which means that you could edit classes you have created with GOOP Wizard 1.0. As a OO-LabVIEW developer, GOOP Wizard 2.0 save a lot of time developing GOOP systems.

In your case, GOOP Wizard2.0 will not solve your specific problem because it is just a new improved EDITING tool and not a new GOOP. I attach a screendump of the new Wizard.

2) Let me explain it to you this way. GOOP is just a software solution to make LabVIEW more object oriented and use all the benifits of object-oriented design and programming. However, GOOP is not suitable for storing such massiv amount of data as you describe. Especially not when the data is growing and LabVIEW has to reallocated memory all the time. Even if you hadn't use GOOP you really should concider the way you store data. Storing arrays of sampled data 44.1kHz for 30 seconds that is millions of samples. This is really heavy work for LabVIEW!

LabVIEW is not alway handling growing data of complex datatypes well and this should really be avoided in LabVIEW with or without GOOP. However LabVIEW6.1 seems to be better than LabVIEW 6i.

My recommendation is that you do not use a GOOP object to store data (it is a software solution and has some drawbacks). An uninitialized shiftregister is more suite because no data copy will take place. But I would for sure avoid storing sampled data in a 2D array that is growing.

Best regards,

Mattias Ericsson
Endevo Sweden
(member of the GOOP Wizard 2 developer team).

[Joseph Oravec]

"Mattias Ericsson" wrote in message
news:50650000000500000038720000-1019262487000@exchange.ni.com...
> 1)
> GOOP Wizard 2.0 adds a lot of edit functionallity that was missing in
>
> In your case, GOOP Wizard2.0 will not solve your specific problem
> because it is just a new improved EDITING tool and not a new GOOP. I
> attach a screendump of the new Wizard.

Excellent, thank you for the more detailed description. It looks much
better, competetive with the german company's GUI.

> 2) Let me explain it to you this way. GOOP is just a software solution
> to make LabVIEW more object oriented and use all the benifits of
> object-oriented design and programming. However, GOOP is not suitable
> for storing such massiv amount of data as you describe. Especially not
> when the data is growing and LabVIEW has to reallocated memory all the
> time. Even if you hadn't use GOOP you really should concider the way
> you store data. Storing arrays of sampled data 44.1kHz for 30 seconds
> that is millions of samples. This is really heavy work for LabVIEW!

I totally understand that this is could be a very non-optimal solution, but
the latency of constant copies in memory is forgivable for the benefits of
GOOP's access-by-reference. It is somewhat hard to describe, but I'm
actually doing very minimal data acquisition. This is more is a
user-interface oriented which is why I stayed away from Visual C++. I agree
Labview may be non-optimal, but a 30-second acquisition should take 5
megabytes or less of storage. Even if it were 10 times less efficient in
storage, the rapid development features of Labview should outweight the
inefficiency.

To the original problem, I was concerned though that the 1-D case didn't
grow in memory requirements but the 2-D case grew unbounded. Even if slow,
it still shouldn't grow in memory requirements. I will probably give NI a
call today to see how they can help, but if you would like my test-cases
which demonstrate this issue send me an email. I'd love to stick with the
Endevo solution, because I dont want to rewrite this huge application in the
LVOT kit.

Thanks for your rapid response! I've used the GOOP on two projects now and
aside from this 2-d array problem I have had great success.

-joey

[Mattias_Ericsson]

Hi again!,

Yes, it would be very interesting to study your test-cases that demonstrate the problem. You can mail me on
mattias.ericsson@endevo.se (I can't find your mail address anywhere).

/Mattias