Split the LabVIEW executable build

[Kyle97330]

---

@BertMcMahan wrote:

There's a chance you could have some large classes due to LabVIEW storing a class's mutation history. Clearing that can significantly reduce sizes:

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

https://lavag.org/topic/14548-class-mutation-history/

---

Good idea, I'd forgotten about that one.

Note that the two linked threads are rather old and don't mention the fact that LabVIEW includes tools to manage mutation history programmatically instead of forcing the issue via renaming the class or manually trimming the XML.  Specifically these VIs:

vi.lib\Utility\EditLVLibs\LVClass\Get Mutation History.vi

vi.lib\Utility\EditLVLibs\LVClass\Set Mutation History.vi

You can use the first one to see just how much space the mutation history is taking (the biggest offender is usually the Variant containing the default data values).  The second one can be used to delete all but the last entry, which is the only one you ought to need in most cases.

The only reason not to do this is if you work under one of these somewhat odd cases:

• You flatten LabVIEW objects to XML and then save them somewhere, and want the ability to open older versions of the XML in your current code
• You have class objects saved somewhere in your code with non-default values and you want those values to attempt to automatically adapt themselves to new non-default values after the class private data changes (these would be class constants or controls with black borders instead of the usual white ones)

The first one you have to do extremely deliberately, and the second one is more often done by accident and is also not generally recommended.

[AdarshaPakala]

Thank you for the information! it is really helpful

I have tried deleting the class mutation but it doesn't help much.

[crossrulz]

---

@Kyle97330 wrote:

Note that the two linked threads are rather old and don't mention the fact that LabVIEW includes tools to manage mutation history programmatically instead of forcing the issue via renaming the class or manually trimming the XML.  Specifically these VIs:

vi.lib\Utility\EditLVLibs\LVClass\Get Mutation History.vi

vi.lib\Utility\EditLVLibs\LVClass\Set Mutation History.vi

You can use the first one to see just how much space the mutation history is taking (the biggest offender is usually the Variant containing the default data values).  The second one can be used to delete all but the last entry, which is the only one you ought to need in most cases.

---

For a good example of using those two VIs, see here: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes.  I turned the snippet into a VI that I keep around my user.lib.  And this just reminded me that it has been a decently long time since I cleared the mutation history of my core libraries.  Now might be a good time to look at that...