Programing in LabVIEW becomes slow.

[P@Anand · Accepted solution]

You should consider using the Arrays and Clusters wherever possible. Also if you want to show controls in the FP try using the Sub Panels, in this was you can breakdown the big VI into smaller VIs and display the controls and indicators whenever required. I believe you are using Tabs, so in this case a SubPanel will work good.

[Yamaeda]

There was an old bug where setting borders transparant would cause the CPU to get stuck at 100%, i guess that's not the case here?

/Y

[JÞB · Accepted solution]

That does sound like nightmare code.  with that many booleans.

When LabVIEW becomes sluggish on a very large project you probably should have split some functionality out to component libraries that have defined interfaces. (And those would be testable)  Beyond a huge restructuring, the best advice is to change the default Opions setting for maximum number of undo steps from the current 99 to the historical default "9."  That undo stack takes a lot of memory with bloated vis and unstructured projects.

Spoiler

Lots, in this case, meaning several thousand vis in your project with poor encapsulation

[Majrocks]

Thank you all for your suggestions, but

still im having the same issue and delay gets increasing to 5 sec to 20 sec as of now i have 300 controls and 150 indicators in my front panel. all these controls are event driven so i cant split that in a sub vi that is one of the draw back and the vi size increased to 10mb and i think i finished only 10% of it. So i dont know where im lagging here so the size has increased and it getting very slow to debug. If i try to copy the entire program to another vi same case there no change but when i try to open a new vi and do any programing its fast so the fault is not with the LabVIEW its with the vi i think so if i make all will come in a cluster then for event driven case. As of now i will try by putting all the elements in clusters the controls and indicators in a seperate cluster and let you know all does this method works.

[Majrocks]

Got the answer why its getting slow its not because of the controls and indicators which your using in your program they will occupy maximum of 100kb if it is 300 controls and 150 indicators the cause of delay its because of increase in size of the program and the cause for the size of the program is due to event structure one when i assign one event i check the size it was 112kb then for the next event it tooks 165kb and third it tooks around 212kb so that is due to the events. Inside every event im using 3 subvi i dont know may be that is causing the increase in size.

[Majrocks]

This is the difference in memory usage im getting when i put add events. As i replaced every thing by clusters but still its taking more memory for that particular vi.

[johnsold]

You said you could not post your VI because of confidentiality issues, but we cannot help you much based on verbal descriptions of your code. Can you create a dummy VI with many controls which exhibits the problem but does not contain or reveal any of your confidential information? Post that and someone will probably be able to identify the problem quickly.

Lynn

[natasftw]

Without seeing your code, it's going to be very difficult to troubleshoot.

It sounds like you're making some crazy "spaghetti" code.  I doubt you need that many booleans.  You certainly don't need an event for each.  You do realize you can put them all into an array and run an event based on an array value change?  Follow that with a quick index check and you can drastically reduce the complexity of your code without losing functionality.

Open up your windows task manager and see how many graphics objects you have. (Enable GDI Objects on the Processes tab)  How many GDI Objects is LabVIEW using?  I'd wager you're getting a large number.

You can't maintain manageable code with 50+ indicators.  The wiring will make your code unreadable.  You're well above this threshold.  Take Lynn's advice.  Remove the confidential pieces from your code and post it.  You desperately need a code review.  This can't happen when we are hearing vague descriptions.

[Majrocks]

Thank you all for your valuable suggestions, I have moved to the sub panel concept which so in one vi i will be having almost 120 controls and 60 indicators so not much of a delay max of 1 sec i got so in this case i can do for the remaining 28 cases which the controls and indicators may vary. I will also upload the dummy code soon for all your reference how my code works . Once again Thank you all.

[Majrocks]

But still Can any one suggest me is there a method to run my labview compiler when i required, because the slow in editing response is due to the auto compiling facility in labview which compiles for each and every move i make in labview which makes my vi slow when i increases the number of functions like assigning more than 30 events. So can any one tell me that, is there a way to make my labview compiler works when i require in this case we can make the editing response faster in labview and the solution for my problem can also be solved but any how im using alternate method of taking sub panel concept for all tabs which i initialized but still if we got the answer for the manual compiling option its the best solution ever.