LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Suggestions for Fixing Sluggish Class Creation?

I have a class that has 50 or so child implementations.

 

Whenever I create a new child class, it'll take LabVIEW about 30-60 painful seconds to create the new class. Similar performance hits occur when I modify class data in children, create overrides, etc.  Working with other classes goes much smoother.

 

Any suggestions for making this a bit less sluggish?  Bonus points for solutions that don't involve code changes!

 

I suspect I could do one of the following, but they all have caveats:

- Redesign so that the base class is an interface.  (This would be an undertaking, especially since I can't just change the class to an interface, but it's on my radar.)

- Only keep a subset of classes in memory.  (An option, but I like having the other instances open as they're useful to reference.)

0 Kudos
Message 1 of 5
(704 Views)

Can you have a project with just the necessary elements in it (base class, 100% required children) and create new classes in that with fewer classes loaded? Do the initial class creation then swap to a full project.

 

LabVIEW does a lot of type propagation and error checking throughout the entire hierarchy is my guess.

~ Self-professed LabVIEW wizard ~
Helping pave the path to long-term living and thriving in space.
0 Kudos
Message 2 of 5
(680 Views)

Is the parent .lvclass file on disk larger than it seems like it should be?

 

If so, by any chance have you changed the private class data of your parent class a lot?  Something that might make it have a very large mutation history in it?  If you let the class auto-version itself, you can see how often you have done this by the last digit in the class rev number (i.e. 1.0.0.12 means you modified the class private data 12 times).

 

If you open the class file as a text file, look for the text <Property Name="NI.LVClass.Geneology" Type= "Xml">, and then look for the closing node </Property> that matches much later on, everything in between there is the mutation history and it can be removed to reduce the memory footprint of your class.  If your class was multiple megabytes in size, this could make the difference.

 

Deleting this does make it so the class and its descendants cannot unflatten previous versions of themselves any more, either from class data converted to XML or files containing class data in earlier versions, but both of those are pretty rare to need to do in LabVIEW.

0 Kudos
Message 3 of 5
(661 Views)

Relevant Idea Exchange entry for clearing class mutation history, including info on a "hidden gem" that can help:

 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-histo...

 

(OP, I know you're already aware of that thread since you commented on it; this is just for future Googler's that see this thread.)

Message 4 of 5
(648 Views)

I've made a habit of clearing out mutation history on a somewhat regular basis -- but this problem seems to persist regardless.  (Although I have certainly seen some general performance improvements in the past after clearing out mutation history).

0 Kudos
Message 5 of 5
(631 Views)