Class Mutations - slow IDE - decide if safe to delete?

[Evan]

I know this is a few general questions but I am hoping you all can help.  Even ideas to look at would be great.

I have a large project with ~500 classes and growing.  I am getting tired of it taking extremely long to load the project in LV 2013.  I get in, hit open and walk away for a while.  20-30 minutes would not be far off.  It also takes hours to build the executable.  I have to build over night anymore.

Then the exe launch is starting to lag into a few minutes or more....  and customers are starting to complain.

So... I wonder if the issue is class mutation histories and how I can decide if it is safe to delete them. 

I do use the MGI Read\Write anything VIs, but only on typedefed clusters, I do not believe I ever save the classes themselves to a file.

So how do I decide if I can delete the histories?  Maybe more importantly do we think that would help?  Are the histories really only used on the flatten and un flatten?  If so if I never store the actual class data it seems to me I should be safe removing them.

Side note: I am also not using "separate compiled code from source" because when I first started this project in an older version of LV I got tired of all the crashes.

[mikeporter]

I don't know if deleting the histories will help. Backup everything and give it a try. I can tell you one thing that definitely is a problem: 500+ classes. Most large applications I write have about that many VIs.

It sounds like you have made a rather fundamental error. Remember that LabVIEW development is like making love, if it's painful you're doing something wrong.

Mike...

[Kyle97330]

Never had this particular problem, but can I ask if this is because you're using the Actor Framework and made perhaps a few too many messages?  

If not, I'm wondering what else could possibly require that many classes.

[tst]

---

@Evan wrote:

Are the histories really only used on the flatten and un flatten?

---

Yes. Note that this isn't only cases where you explicitly save to a file, but also things like default control values in VIs or if you transfer the value over a network, etc.

As Mike points out, assuming you have SCC (which you should), it's simply a matter of doing it and seeing what happens. If something goes wrong, just revert to the stable version. I expect there shouldn't be any issue with deleting the histories, and from what I hear it might help, but it's not a guarantee.

Another thing which can greatly impact load and edit times is having circular dependencies (e.g. class A has a value of class B somewhere and class B calls a VI from class C and class C has a class A constant), so you would want to break those. In general, when getting to large app sizes, people often switch to less static dependencies between components, which generally means LV has to load and resolve fewer things. The best practices group ( https://decibel.ni.com/content/groups/large-labview-application-development ) probably has some discussions on this, as would the AF group, particularly when discussing zero coupling.

[Evan]

Hey Tst,

Thanks for a the answer.  I wasn't sure if I would see any bugs due to the delete right away.  I think it is most likely the circular dependencies that have caused the issue, and I am not sure how I will break some of them.

In regards to the other posts

I will clarify the application.  I also just re-loaded it and it was closer to 10-15 minutes so it may be that I have just been taking a little too long getting my coffees. The exe launch can still hit 5 minutes, but is generally only a few.

The architecture is built basically like the actor framework (though not actually the actor framework due to the age of the original project).  So there are literally 100s of messages (each a class inheriting from parent action classes).  The code controls multiple models of an industrial machine.  Each model having different combinations of flavors of data acquisition, motion control, external control boards, internal data processing, operators levels, languages etc.

Due to the multiple flavors of each component I choose the object oriented model so that as a new model or data acquisition device is needed for a new model I can simply overload the existing classes.  The current VI count just in the project folder itself is ~4000 though obviously a lot of those are accessor VIs etc.

There are currently 5 different models plus a base class there.  Similarly there are 4 different digitizers, 3 different motion controllers, 4 different output models, etc.  So those classes are similar to Actors with children, and then the messages for them. 

The motion control messages are currently at ~50 classes there that equals about 150 VIs.  Items like Set Targets, Go, Set acceleration, Enable, etc.

If what we are doing is just a lot for LabVIEW and this is the cost of doing business with LabVIEW so be it, I am just curious what may define some of these issues.  I also may eventually move to the actual actor framework, but at the moment that isn't an option.  I am also curious what class and VI counts seems reasonable for an application of this scope and requirements?  Why did 500+ strike everyone as large?  I feel like even the Soft Front Panels had thousands of VIs, but that has been years.  We are using the SEA LTK localization package and they have 700 VIs to implement localization.

To be honest if I can fix the EXE load time I would be happy, so I have thought of adding some pre and post build steps to strip out some of this if I need to.  I may just make different EXEs for each flavor of machine and strip out the other classes, but that means 1 code base making multiple EXEs....

Thanks

[mikeporter]

You need to be clear on this point: what you are experiencing is not the cost of "...doing business with LabVIEW...". It's the cost of developing an application using a poor methodology.

Learn from your mistake and don't repeat it.

Mike...

[Evan]

Mike,


What is the mistake you keep alluding to?  I would ask you to clarify what is the "poor methodology"?  A large application that has a lot of messages between a lot of independent modules using classes and inheritance is bad?  Utilizing architecture similar to the Actor Framework?  Using Labview for a large project?  You seem to be acting like a LabVIEW troll, you have literally no idea the scope of my project but are drawing these conclusions about my abilities and design based solely on size.

To turn it around.  If someone told me their "large" project had only 500 VIs or functions I would be inclined to think it was poorly designed and was not properly using subVIs.  I am using the SEA LTK toolkit that is used to localize a project and it has over 700 VIs.  Is it therefore poorly designed?



I am asking about issues that are obviously related to the LabVIEW IDE (load time), and all of us that have used LabVIEW for years are familiar with the various "costs of doing business" with LabVIEW.  Hell a few years ago when you and I were talking about this same project and some crashes I was seeing (http://forums.ni.com/t5/LabVIEW/Access-violation-0xC0000005-at-EIP-0x013C7314/td-p/2258546). You are the one that points out that LabVIEW and classes are not implemented similar to other IDEs and languages.  You even "rant" about it.  These issues are partially why we all love and hate LabVIEW.  There are costs of doing business in LabVIEW that are LabVIEW specific.


So if you are truly saying that LabVIEW cannot handle a project with large class and function counts then I would say that is a cost of doing business with LabVIEW and an issue LabVIEW needs to fix.  If you were working in any other IDE and where told that the IDE simply will not function in a reasonable fashion (i.e. long load times for the IDE or the executables) when you exceed a few thousand functions (VIs) you would be laughed at.

tst's suggestion to look at circular dependencies on my classes makes sense and is something I can explore and attempt to fix.   But still that "fix" is only so the LabVIEW IDE will behave better, and is not indicative of any poor design on our part.  Again, if I had the same design in a different IDE the IDE itself would behave... even if the code did not.


So, at the end of the day this is still all about the LabVIEW IDE and how to get it to behave better.    The code executes and scales extremely well as code... it is the IDE that is struggling NOT my code.  We all know that there are a lot of things that you have to do in LabVIEW that you would never have to do in other IDEs and that is why I reach out to the NI customer base and not to general programmer base.

So thanks again tst.  If anyone else has some constructive pointers I would appreciate them.

[drjdpowell]

---

@tst wrote:

Another thing which can greatly impact load and edit times is having circular dependencies (e.g. class A has a value of class B somewhere and class B calls a VI from class C and class C has a class A constant), so you would want to break those. 

---

I suggest you time your load times carefully then work on breaking some unneeded dependancies.   Open a new project and add one of your classes to it, then look at in dependancies for all the things that load with it.  Only things that the the class logically depends on should load.   If other seemingly unrelated code loads then try and identify and break the "links".  Often, these are "optional" VIs that use two classes that have been placed in one of the classes.  Improve the dependancy tree a bit (it should be a tree, not a nest) and then see if load times are improved.  If so, improve it some more.  Evnetually you can move to dynamic loading of many of your classes,

[drjdpowell]

Oh, and ask on the AF forum about load times with large numbers of classes.  I'll bet someone has 500+ and you can compare (I don't use class-messages and my largest project only loads about 80 classes, so I can't help).

[Evan]

Yeah I have looked at some of the circles that are created and they can become extremely sticky to break.  There are simply times when two classes do depend on each other. 

For example, we have a motion controller that has inputs.  Well depending on the model of machine those inputs mean different things.  Ie input 1 is a limit on one model but a home on another.  So when the motion controller updates it status it needs to ask the model where to put things.  Well later the model wants to know if it is home... so it has to ask the motion controller the status of those limits.  Obviously there is more to it than this, but what happens is there is a parent class "Machine" that has all these other classes as children.  A machine has a "Motion Controller" a "Model" etc.  Well each child needs to be able to call up to the "Machine" for things.

Then all the actors that are doing things (the actual motion actions etc) also need to ask the machine things.  In addition there is the class that has all the actor queues that every object uses to enqueue the messages to other objects.  So very quickly all the classes are grouped together and loading one forces everyone to load.

I have looked at packed libraries and a "plugin" architecture but that is obviously a very large undertaking to convert a working project with so much inheritance to pieces and parts that are fully separate.  Or I can actually increase the class count by trying to add more and more messages as far as "Get me this info" rather than just calling the dynamic dispatch subvis directly. 

It seems to me that a lot of what I am seeing is just what it is, and there is not any easy changes to make to really solve it.  Even moving to the formal architectures still may struggle with these so.. it is what it is.  It is hard to justify spending all the time in the attempt to solve a maybe.

Thanks for the ideas though.