LabVIEW
Slow LabView 2016 IDE
Solved!
@natasftw wrote:
One easy way to see if the compiler optimization problems mentioned are your problem is to open a new VI. Do you see the same behavior? If not, you likely are running into code complexity issues.
You can also try lowering the compiler slider in the Tools > Options menu as another data point.
@EWiebe wrote:
* Yes, MyComputer as target, No RT, No FPGA
* No Web Services
* Yes, one Conditional Symbol !
* Yes, it is "ProjectName.lvproj/My Computer"
BTW: Yes, it is german 😉
Thank you very much!
First, Please contact your local NI Support rep Make a back-up of that project and its dependencies and deliver it to NI. R&D Really needs that example.
Next, Check you Private messages for a LabVIEW ini token that I would like you to try adding to your system. Add the line with LabVIEW Closed then open the project and report back any changes to the IDE Performance. (Just Sent!)
Your code has a cyclomatic complexity of 448. 5 is "Normal" 15-20 is considered "Hard to maintain" I have personally never attempted to modify code greater than 85ish (It was awful-and did not work correctly when I started).
Don't bother with changing the compiler settings in the tools>>Options>>Environment. That high of a Cyclomatic complexity nearly guarantees the compiler optimizer is going nearly insane trying to dissect the code.
That helps NI Find the root cause of the IDE slowdown but does not address your larger issue. Your main issue is that you have a "Frankenstein's Monster" of a main vi. It likely grew from various pieces parts harvested from code that was buried and pieced together to form a "Superior.vi"
We need to look at finding means to help you get control of that monster.
The VIA results offer some places to start. Pay attention to VI Properties>>Memory as you go through all of these steps
- Get the data memory footprint reduced: Look into the results of Array Default Values. See how much memory you can free by either loading that data from a configuration file (Files) or simply emptying the data if it is not useful.
- Nested Structures: You have several deeply nested structures! Usually that means the construct's purpose was overly broad (God Structure) we can help you re-work those more meaningfully and, BONUS, instill some better software design practices that will help you down the road.
- Basic Maintainability: Hidden/overlapping objects and objects with duplicate names. Easy fixes. And while we are at it lets start adding comments on structures so we know what its supposed to do.
We should also look into why there are 35 Write Globals, 34 Write Locals (smells like a mess) There are better options but we need to understand your use cases
108 Controls and 116 Indicators? That is WAY TOO MUCH DATA for a user to grasp and use properly. Go back to your user and get the "User's Story." What does the user really need? A Configuration page? Great split out a Config Dialog.vi! An "at a glance" summary of system condition? Outstanding- give them a simple status display! Details of history/trends- Any TDMS file viewer will do for that! Don't burden the user with anything that is not needed to run the system.
I'm betting that we can reduce the Cyclomatic Complexity by at least an order of magnitude, restore the IDE Responsiveness and result in a better code base on top of it all.
And again THANK YOU! very much for sharing these observations with us.
@EWiebe wrote:
The memory usage of my main vi shows:
see attached picture
complexity: 11
(btw: the here called main vi (SUB Prüfung Sensor.vi) is not the top main vi in my project but it contains all relevant code )
(how to insert pictures directly into forum messages?)
Create a *.png using the Windows snipping tool (it helps to have it here)
Then hit the highlighted "Camera" icon and
Browse to where you saved the png and select upload towards the bottom of the dialog
