Old content remains in lvclass files

[Steen Schmidt]

Hi,

 

I've decided to take the temperature on a known issue, that lvclass files retain knowledge of some of their old content after it's deleted.

 

Proof

For some reason I'm not allowed to upload lvclass files, so I'll describe it instead (using LV2014SP1):

 

1) Create a new class and save it on disk as class1.lvclass. No member data nor methods, file size on disk is 8 kB.

 

2) Add one piece of significantly sized (to easier see the issue) member data, I added a 1000x100 array of DBL (with random default data in it). Save the class again, and now class1.lvclass is 4604 kB (why so much, should be around 1000 kB?).

 

3) Delete all member data again and resave the class. File size on disk is now 1171 kB, I'd have expected 8 kB.

 

4) I can't ever get rid of that extra data in the lvclass file, not even when I "save as" to create a similar class.

 

Questions

A) What's the reason behind this issue?

 

B) Is there any way to really delete stuff from a class file, or is the only way to recreate every class from scratch if you want something truly gone?

 

C) Is there a list (perhaps internal to NI) of which problems this issue causes? Here I'm talking about stuff like this and numerous other threads about class data suddenly not being updated or member data or methods not being called correctly with DD.

 

Cheers,

Steen

[JKSH]

The LVClass remembers its previous states in its Mutation History. If I'm not mistaken, NI designed this to help VIs that use your class to adapt to the newer version.

 

There is currently no way to delete mutation history via the LabVIEW IDE itself. Your options are:

• Delete it from the *.lvclass file directly (it's an XML file): See http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-history/idi-p/2594921
• Use these NI-created VIs to delete the history: http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B

[smithd]

(A) Don't know why its an unusual size.

(B) If you delete the entire genealogy section in the xml the size goes back to normal.

© I've never had this cause an issue, but I would imagine its not officially supported. The genealogy is probably unrelated to those issues you posted, but it will cause issues if you try to do unflatten on old data. I don't have a need for this feature, so I delete the data pretty regularly. Makes RT deploys a bit less painful too, or at least it does in my imagination.

[Steen Schmidt]

 

The LVClass remembers its previous states in its Mutation History. If I'm not mistaken, NI designed this to help VIs that use your class to adapt to the newer version.

 

There is currently no way to delete mutation history via the LabVIEW IDE itself. Your options are:

• Delete it from the *.lvclass file directly (it's an XML file): See http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-history/idi-p/2594921
• Use these NI-created VIs to delete the history: http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B

 

 

So a built-in feature. I'd still like some official response on these topics then:

 

- Exactly how does this help VIs adapt to a newer version? In my experience new versions of classes aren't more robust than new versions of clusters. And as far as I know clusters do not log around such huge sections of old state.

 

- Is the default value of each data field really necessary to store? Or could we shed 1.1 meg from the class in my example and just store the name and type of old data members?

 

- Is the history really necessary to drag with us onto new copies of a class? Typically I find I mostly copy a class to avoid doing some similar work again, not because I'm creating a new version of it.

 

/Steen 

(A) Don't know why its an unusual size.

(B) If you delete the entire genealogy section in the xml the size goes back to normal.

© I've never had this cause an issue, but I would imagine its not officially supported. The genealogy is probably unrelated to those issues you posted, but it will cause issues if you try to do unflatten on old data. I don't have a need for this feature, so I delete the data pretty regularly. Makes RT deploys a bit less painful too, or at least it does in my imagination.

 

A) Perhaps worth investigating internally at NI then?

B) Not something the average LV dev will or can do. And I have had devs ask me why their classes keep growing in size.

 

/Steen

[shoneill]

Every class (as opposed to every object) stores its default value.

 

Even when writing to a class via a static Accessor, overhead in combination with storing whether that object has default data or not leads to writes being slower than similarly designed clusters.

 

This "default data" behaviour also raises its head when flattening to XML as only the OBJECT data is saved, not the DEFAULTOBJECT data.  So every object points to a default instance of it's own class in memory where the default values are stored.  For this reason, mutation history may be more important as the objects themselves saved to disk have no idea of any changes made to the non-saved default values of previous generations if it's not stored within the mutation history.

 

I find it a very unwieldy construct but my opinion on the matter is most likely rather insignificant.

[Steen Schmidt]

Every class (as opposed to every object) stores its default value.

 

Even when writing to a class via a static Accessor, overhead in combination with storing whether that object has default data or not leads to writes being slower than similarly designed clusters.

 

Yeah I know that this is the main reason behind the slow object writes we experience when comparing with clusters. Reads are fast, writes not so much. But all is relative.

 

This "default data" behaviour also raises its head when flattening to XML as only the OBJECT data is saved, not the DEFAULTOBJECT data.  So every object points to a default instance of it's own class in memory where the default values are stored.  For this reason, mutation history may be more important as the objects themselves saved to disk have no idea of any changes made to the non-saved default values of previous generations if it's not stored within the mutation history.

 

Ok, I now understand the reason behind choice of mutation history. I'm not sure I like that very much. For one it is still not guaranteed not to fail (the mutation history is only intact as long as I don't delete it), and it forces a lot of comparison and will result in slower than otherwise necessary load times. And it is inconsistent with every other object type in LabVIEW. Not that we shouldn't change just because something else is already implemented...

 

I wonder what tipped the scales toward this design decision? Perhaps that classes were seen as containing large default data constructs primarily? It smells a bit like that shared variables are optimized for single point updates and suck for streaming (not comparing classes and SVs at all btw). I'd rather have the possibility to specify data with a 'static' keyword for instance, and only in those cases get this behavior. If I could do that I could decide when to trade in memory usage for performance and hard linking.

 

/Steen

[Neil Pate]

In the seven or so years I have been dabbling with LVOOP not once have I said, "gee I am so glad that a class maintains its mutation history". Maybe it's just the kind of applications I develop, dunno. I never serialise my classes directly to disk.

 

Also have seen some terrible editor bugs that can be traced down to stale mutation history in a class.

[JKSH]

In the seven or so years I have been dabbling with LVOOP not once have I said, "gee I am so glad that a class maintains its mutation history". Maybe it's just the kind of applications I develop, dunno. I never serialise my classes directly to disk.

 

I've dabbled for about 1 year, and I haven't needed wanted mutation history either. I have a VI that recurses through my project folders, stripping out all mutation history before I commit my files into source control.

 

 

The current serialization system needs a major overhaul; AristosQueue has a side project to improve it: https://decibel.ni.com/content/docs/DOC-24015

[ThomasGutzler]

If I understand this correctly, one way to get rid of the mutation history is to not change the class.ctl.

If that's the case you could, for example, store a reference to your actual class data in this control, which you can then change as often as you wish without LabVIEW knowing about it. And that takes us, once again, to GDS

The problem with this approach is of course that flatten to string on an object doesn't work any more and you'd have to write your own flatten method, which flattens the data the reference points to instead of flattening the pointer value. Hmmm

[Neil Pate]

Bump to this thread. I really do not like mutation history being stored.

I have a stupid LabVIEW bug where the IDE thinks I am using a class which I am not (really am not). I thought perhaps it was being referenced from the class mutation history. So I poked around in the history of some of my classes and am horrified at the history that exists! I don't know about others, but my standard framework has been adapted over time (several years for my current actor based framework). I still have references in the mutation history for application specific classes from my original project! Urgh... 

I suppose I have no excuse, I have known about this "feature" for a while, but it is easy to forget about.