Long save times with Large GUI application

[Relec]

I have a GUI program for controlling an ROV.  It has 12 tab panels for various control screens, each screen may have up to two nested tabs.  There is a Static screen around the Main Tab Panel containing controls to access each screen tab and provide "important information " that needs to be viewable at all times. 

The architecture is a Queued State machine consisting of an event structure and 6 parallel loops (Main consumer loop, Timing loop, Communication loop, Static Display loop, GUI Front Panel Display Loop, and a loop to deal with Pop-ups).  The architecture works great and I am having no problems with it (from what I can tell). 

I am finding that whenever I hit SAVE - I get the spinning circle for about 1 minutes, then it says Not-Responding for about 30 seconds before the save completes.  As I have a tendency to hit save fairly often, I estimate I easily waste 60 minutes a day waiting for the save to complete.  Note – it does not produce the long save time for every single save, only some.  Usually after adding or moving/editing a control or indicator. 

The long save times started to happen when I added in my Diagnostics tab panel, which consists of approximately 712 digital or analog I/O controls or indicators.  Many of these controls/indicators are duplicated on the Configuration and Alarms Screens with different functionality, and will or do have property nodes associated with them.  Those 3 panels likely account for nearly 2000 indicator/controls, of which only 32 would be visible and updating at any one time.

I am using an i5 with 8 GB of ram.  I switched to 64-bit Labview to try and remedy the problem, but have seen little or no improvement.  I was using a large Global Shift register cluster as an input to each loop and many of the subVIs, and have since broken that down into a series of smaller clusters.  That improved things somewhat, but additional clusters will be required as the program evolves.  When in the development system, Labview uses at most 600 MB of memory.  The executable uses about 120MB of memory and 60% CPU depending on the panel being displayed and this is well within the specifications. 

I thought about using SubPanels instead of Tabs, but it would probably require a signification modification of my current architecture and I am running short on time.  Any suggestions on reducing this save time?  Would it make any difference if I displayed the I/O as clusters (grouped the I/O according to cRIO modules), rather than an indicator/control for each channel. Would I benefit from more RAM? 

Due to NDAs, I am unable to post any of the code. 

Thanks

Relec

[RyanPoPo]

Hey Relec,

It's hard to say what is causing the long save times for you. You do have a very large number of controls/indicators, so it may not be unexpected to have long wait times when the code and front panel configuration are being written to file on the HDD. What version year of LabVIEW are you currently using? WIth each release of LabVIEW, the performance is tweaked and improved, so if you you aren't using the latest version then upgrading may alleviate the long save issue for you.

Regards,

Ryan

[billko]

This link might shed some light on the issue.  (It was the first link I saw that described recompiling.)

[Relec]

As a solution to my own problem. 

I re-designed it with Sub-Panels, so each tab was a separate sub-panel.  This way, if I had to make any changes to a specific vi, I was only making a change to that sub-panel and not the entire main program.  By breaking things up this sped up the time required for saving the Main vi. 

I also reduced the number of controls/indicators on some of the busier panels by making them generic and attaching variable text indicators with each I/O.  That way I could limit the number of I/O controls/indicators.  This doubles the number of controls/indicators for one I/O module, but if you go beyond 2 modules you get cost savings (we use between 5 and 9 similar modules). 

Relec.

[Eric1977]

You may want to consider a queue to Save your data. Even though you stated that subpanels helped quite a bit, at least your UI wouldn't suffer by having it's own Save queue.