Why Labview wants to save 50% of VIs after altering a single subVI?

[Sebastian.Weber]

Hello!

I have about 250 classes in LV2017, which all make use of one VI at several locations in their code.

Now, I have made internal changes to that VI. I did NOT change the terminals or their data types.

When saving this VI, LV freezes for a few minutes(!). And when saving the project, LV starts to save about 100 VIs wildly distributed over the classes. That means, LV wants to save a large fraction of VIs which use this single VI, but by far not all.

Why is it so? In general, there is no need to touch all the VIs, because the terminals of the changed VI did not change. If LV still thinks it's necessary, why does it not want to save ALL VIs?

All classes and VIs are shared-reentrant, and the compiled code is separated from the VIs.

[wiebe@CARYA]

LabVIEW does try to propagate specific class types through VIs. This is usually helpful.

For example, consider a VI A that accepts and outputs Parent B. If you wire Child C, the output is usually Child C even if the VI doesn't have DD terminals. This is only possible in some cases. It's not always possible, for instance if the non DD terminals are in a DD VI. This can change after editing the VI (or any override of it). Perhaps changing the VI triggers the test for this?

Does this happen for all VIs, more than one, or just for the one VI? It could be a corner case. 

It could be possible to stop this with a Preserve Run-Time Class function at one or two strategic places, although that usually only helps if LabVIEW can't work out the output class type.

It's had to say without any code...