Best practises: organize large application

[downwhere]

Some background:

We have several large LabVIEW applications and the latest project we are working with have almost 9000 VI's. The application is used for simulating the environment for a control system so that we can test the logic of the system. The application consist of several layers:

Graphical layer

Application interfaces layer

Application logic layer

Signal interfaces layer

Hardware layer

We used to develop our applications with an older version of the GOOP toolkit but for the latest project we been working on for over a year now we started to work with labVIEW classes. This gave some huge benefits regarding the performance of our applications but also gave us some new problems. We started to use the Project Explorer and for each layer we created a Virtual folder and put all classes in its corresponding layer.

Some issues we are facing today that we are trying to improve:

1. We used to have a GOOP class in a LLB file, we now have a LV class and all it's VI's as several separate files which takes longer time to load. For the complete project it take several minutes. Earlier with the GOOP classes in LLB's it loaded a lot faster.
   
2. As the .lvproj file contains a link for all classes in project we get some "conflicts" when we are several developers that need to create and remove classes to the .lvproj.
   
3. Unresponsive development environment, it take a few sec here and there to wait for some minor operations when we are developing.
   

For the first issue i'm not sure how to improve, is the only choice we have to use LLB's or can we do it in another way? I been looking into packed libraries and perhaps we can create a packed library of some of the code that we rarely updates. But I think we do too many updates to all layers during development so packed libraries might not be the right path to choose anyway.

Regarding the second issue and also for the first issue regarding creating packed libraries I converted the virtual folders (one for each layer) into a .lvlib file it took like one day to compile and save for each layer, so 5 days totally. By doing that the .lvproj file only included a link to new .lvlib files so we shouldn't get so many "conflicts" with the .lvproj file when we are several developers working on the same project. Also I could try to create a packed library of some of the layers that don't changes so often to speed up the load time.

To my surprise when the conversion to .lvlibs was done it now takes about 50min to load the project (the .lvproj file). Does anyone know what happened and why it take so long time now?

Regarding the third issue, unresponsive development environment we are not sure how to handle that as well, it just take a few sec here and there when we are developing. Is it because of all 9000 VI's in memory? I read about the new functionality in LV 2012 about you could set the code complexity for each VI. would that help you think?

As you can see we have some issues that at the moment isn't any show stoppers but we're not so happy we the current situation.

I'm looking for some best practices for how to organize such a large labVIEW application in a .lvproj project file. Do you use several project files and lvlibs or how do you do? Are there anyone here that can share some knowledge on how your team/company organize your large applications to address the same issues that we have.

Best regards

[fabric]

I'd say the single best thing you can do to fix all (yes, all!) the issues you mentioned is to restructure your code with the intent of simplifying the dependency tree and reducing cross linking.

If many of your libraries are statically dependent on other libraries then you can quickly end up with a very complex dependency tree. This is compounded when using classes since loading any class member causes the entire class to load, as well as any owning libraries. (Sticking a bunch of classes in a .lvlib can cause major IDE slowdowns...)

Many of us have seen great benefit in using interfaces to abstract the low-level layers from the application layers. This is a big plus for multi-developer environments and for improving load time and IDE performance. You might want to read up on the Dependency Inversion Principle.

A few lava links:

• http://lavag.org/top...d-vi-templates/
  
• http://lavag.org/top...existing-class/
  

And you might want to vote for this idea over on the blue side - you could be vote #100!

• http://forums.ni.com...s/idi-p/2150332
  

Edited December 13, 2012 by fabric

[downwhere]

Thanks for your feedback! I appreciate it.

We have started to refactor some of our the code using Factory pattern, dependency Injection and we should also look into the dependency inversion principle to decouple our layers and to improve our load time. I think it will be to much refactoring for this project at the moment, but for the next project we can easier make it right from the start with these design patterns in mind.

I voted for the idea at the idea exchange, but someone hit the number #100 before me, i was number #101 =)

Thanks again!

[PJM_labview]

Like you we have been experiencing this slowdown for years as we routinely have project using classes with 5k or more VIs.

In respect to "fabric" comment about refactoring/restructuring your code, this may help but it is a sad reality when you have to dump a perfectly valid architecture for a another one simply because the LabVIEW IDE make it unusable.

With 9K VIs I shudder thinking how long it will take applying a typedef changes given that in our framework this sometime can take a couple of minutes.

Regarding solutions: The single most bang for the buck that we have found is to NOT use the project. This help a lot. Just open the lvclass you need to work on in memory. Even if you where to open all your classes one by one, as long as you are not using a project the IDE will be significantly faster (compared to have the same classes in a project).

By the way, I got fabric's Idea to 103 now.