LabVIEW 2009 slow performance

[Ben]

---

rickygolf wrote:

I know how to use sub VI's to change the GUI with global variables, but I'm not sure how this will help.  I am interested in shrinking the code size and speed if you could give me suggestions.  I used captions as the pin names because it was the only way I could rotate text.  I couldn't figure out how to do it with a string.  I'm not a software guru, but as far as LabVIEW is concerned, I don't think my code should be causing this much trouble. 

One thing I do want to go back to is the memory usage.  When I open this VI, under task manager performance it says I'm using ~500 MB of RAM.  When I save the VI or run it, the RAM usage jumps up to ~1.15 GB.  When the save is complete or I stop the execution of the VI, the RAM usage does not go back down to ~500 MB.  It stays at around a GB.  Why doesn't the RAM usage go back to ~500 MB.  If I close LabVIEW and reopen it, the RAM usage is back down to ~500 MB.  Can you explain this? 

---

1) Any caption that is not changing at run time does not to be explicitly set. Just type the right text. Toss all of the proprty nodes that are writting the cations if they never change.

Every one of those property node has code buriied in them. Moving that work to a sub-VI will get that memory demand out of the top level VI.

LabVIEW Memory managemnet code is very good at keeping that stuff working without any effort on our part. But because it can not "read our mind" it plays the game safe and only allocate memory when it is required and does not give it back until it is clear we will not have to allocate it again soon. It is clear that we will not re-use memory when a VI closes (you have seen this when you shut-down LV and the memory comes back). You can explicity de-allocate memory when a VI stops.

2) All of the controls being used as variables each have to hold their data, display it if you slide over to where the indicator is, as well as maintain a "default" value for each. Tossing all of those extra controls and replacing  them with an Action Engine or some other logic will alos cut-down on your memory useage.

Ben

[rickygolf]

If I select "Set as Defualt State" in the menu options on the front panel, will these settings carry over if I create an executable.  I'm trying to cut down all the init code. 

[Ben]

---

rickygolf wrote:

If I select "Set as Defualt State" in the menu options on the front panel, will these settings carry over if I create an executable.  I'm trying to cut down all the init code. 

---

AS I understand it, and barring no bugs that i have not heard of, yes.

But please test this first before you throw away all of the code. (You would be justified in being very pissed-off at me if it didn't work).

Just trying to help,

Ben

[rickygolf]

I think it would be some my fault too if I just started erasing and deleting.  I want to learn more about this Action Engine thing you mentioned.  I might be creating a huge peice of software using LabVIEW here soon, and I want to be able to code effeciently.  I have done many large LabVIEW programs, but this time I will be more concerned with graphics.  I wish I could get a hold of the presentation the Bloomy presenter gave using LabVIEW during NI week.  Thanks for your help.  Your response time has been great. 

[Ben]

Here is a link to my Action Engine Nugget.

Put some effort into how you can organize your data so that related values are together and not all in one pile (1 cluster).

Feel free to post more question so that we can keep you pointed on the smooth road.

Have fun!

Ben

[DFGray]

Ben is being remiss in his suggestions by skipping a couple of other options .

Check out the data value reference (easiest) or single-element queues. With action engines, they are the thread-safe, encapsulated, global data objects I would recommend.  Which you use depends on what you are doing and your particular preference.

Don't forget that the wire is the best data object.  Locally, this usually means a feedback node or shift register.  But it could mean a simple wire.

Message Edited by DFGray on 09-01-2009 08:21 AM

[EWTech]

Are there issues with .NET 2.0 DLLs now? My original project used LV 8.21 and has successfully moved through to 8.6.1. The current version (9.0) is just dog slow. There are lots of GUI elements but, since that is the function of the vi, I'm not sure what you would suggest to fix that...

The same project built using 8.6.1 executes immediately. The version created using 2009/9.0 takes over 90 seconds to display on the screen and another 8-9 senconds to update to current values from network variables. This is my second query on the forum and the engineer that I spoke to at NI seemed to get lost on details like where the DLL path was set to in the project file. It's where it belongs in the project but this just wasted a bunch of time. The issue seems to be the Windows XP 32-bit target. If the newer version of LabVIEW is not appropriate tfor use under Windows XP please just make that clear to us. Topping memory up to 4 GB only helps if LabVIEW is already open. If the executable file is opened as a binary built using the binary builder in the Pro version the executable always takes 90 seconds to load.

[BCho]

Hey EWTech,

This question may get more attention if it is entered as a new thread. Here are some questions that may help give more information about what is actually going on. Is this one project that has migrated from LV 8.2.1 to LV 2009 or is this a new project in LV 2009? Where are you seeing the hang, is it when you open the project itself, when you open your main vi, or when you try to run the main vi? Can the slow performance be attributed to any particular portion of your code?

[EWTech]

I actually created a new thread about this a while back and it seems to have been buried...

 The project was originally culled from 8.21 code that has steadily been maintained through the various versions since. I have, in desperation, recreated the project as a 2009/9.0 project and this does not seem to have had any effect. I'm sort of used to finding broken wires in old LV code that is being "ported" to a newer version but the slowdown I'm seeing looks an awful lot like a native LabVIEW issue. I attempted to speed things up by adding memory (to 4 GB) to no effect. This machine in question is a P4 (Netburst) machine. The DLL has been used in all versions of LabVIEW between 8.2.1 and 8.6.1 inclusive. This issue seems to be an issue specific to 2009/9.0.

The DLL being used is a .NET 2.0 assembly created with Visual Studio 2005. If things seem to work better with Visual Studio 2008 I'll lobby to get the latest version but I have to know that is the actual problem.

The killer here is that the project, code and DLL assembly work perfectly in LabVIEW 8.6.1. The project is build as a binary file using the builder for deployment on machines throughout the lab. So far I have stuck with LV 8.6.1 for current projects but there is always the problem of how long I can get away with that.

Message Edited by EWTech on 09-16-2009 05:55 PM

[iZACHdx]

Hello,

Have you taken a look at your task manager and compared the resources between running this on Lv 8.6.1 and LV 2009? Is there any significant differences between the CPU and memory usage between the two that might suggest a problem with one of them?

-Zach