LabVIEW 2009 slow performance

[rickygolf]

I have created a VI that is 4.5 MB in size.  The problem is when I'm editing the block diagram, LabVIEW 2009 hangs and gets very slow.  It takes the program at least 3-4 minutes to save.  Anything I change on the block diagram takes 30 seconds to update.  This is anything from deleting a wire to creating a local variable.  I checked the performance tab in the task manager and when the VI is NOT running and I'm editing the block diagram, LabVIEW sometimes uses over 600 MB of RAM.  I only have 1GB of RAM so this causes my computer to start using virtual memory.  I guess that is why LabVIEW is so slow.  My questions is why does LabVIEW start using 600 MB of RAM when my VI is 4.5 MB.  This seems like a lot.  I even tried my VI on another computer with 2 GB of RAM and it was still very slow.  Once I try to run the VI, it takes a couple of minutes to start running, but once it does it is not slow for the most part.  What could the problem be?   

[Ben]

Check your VI metrics paying close attention to the space allocated for "Data".

If you have a lot controls and locals with default data savd in them, then ... well you can guess ath the rest of the story.

Ben

[rickygolf]

I guess I might have a lot of controls and variables initialized at the beginning of my code, but I would very surprised if it was enough to slow down LabVIEW this much.  Here is the information from the memory usage window in VI properties.  Let me know what you think.

Front Panel Objects: 263.9K

Block Diagram Objects: 13866.9K

Code: 9731.8K

Data: 2570.5K

Total: 26433.1K

Total VI Size On Disk: 4576.2K 

[Ben]

If your code runs OK and the issue is only durring development then buying more memory is probably the most expedient solution.

Thought bihind the above:

Virtual memory is is a way to extend the memory map beyond what is physically available by making use of a disk drive. But disk drives are orders of magnititude slower than physical memory so you run into slower performance.

Whne Virtual memor is in use, the phyical memory is continually loaded from disk ask each block of memory is accessed. Whatever is the oldest get put on disk and the physical is then re-used and remapped for which ever block of ememory that is about to get crunched.

When developing you have to access more than just the codeso the page swapping commences.

When running, only the code is used so after a short periuod of time the memory that WAS holding your VI documentation gets writtein to disk and that physical memory is now used for your app. The stale data just lives on disk.

As long as your app stays below the physical memory available, you may never notice how close you are to the edge.

Try posting that code to this forum (it the forum will allow it!) and we may be abelt offer more concrete suggestions.

Ben

[smercurio_fc]

---

rickygolf wrote: 

Front Panel Objects: 263.9K

Block Diagram Objects: 13866.9K   <--- this seems like a lot

Code: 9731.8K

Data: 2570.5K

Total: 26433.1K

Total VI Size On Disk: 4576.2K 

---

Do you have any large array constants on your block diagram? Can you upload your VI? Compressed, please since it's already at 4.5 MB.

[rickygolf]

I have created a pin multiplexing tool for a microcontroller.  There are 3 VI's.  The main VI is multiplexing.vi. 

[TCPlomp]

I even find >9 kbyte of code quite a lot.

Ton

[rickygolf]

I forgot to take out the sub VI under the Continue event in the event structure.  I'm working on that sub VI right now so just delete it or I can repost the zip file with it deleted. 

[Ben]

Hi Ricky,

I'm not here to beat people up over their code so I will not comment any more than I have too do.

The code is that large because

1) of all of the controls and indicators plus property nodes you are using. When I develop apps with this much happening on the GUI, I will write sub-VIs to handle all of the GUI appearence updates.

2) You are using off-screen controls and indicators like they are variables in C (they are NOT variables!).

If this code runs OK then I don't know if it worth the trouble to change it.

If you want to use this as an achedemic adventure into "how should I have written this" then that is a different story.

My gut says "spring for the memory" AND learn how to use sub-VI to control and interact with the GUI.

Ben

[rickygolf]

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?