[Bug?] Sort 1D Array.vim adds 600KB+ to vi file size

[Basjong53]

I noticed that some of my files were too large (600-700KB) even though they contained very little code. It turns out that the "Sort 1D Array.vim" function adds 626KB to the file size, just on its own. I've uploaded a new vi (LV2021) containing just the "Sort 1D Array.vim" function, notice the size. 

The actual "Sort 1D Array.vim" function itself is 624KB (why is it so large anyway??), but that doesn't explain why VI's calling the function become large as well.

[santo_13 · Accepted solution]

For the latter part, all VIM are inlined into the caller, so, it partially makes sense that the caller size will increase.

[Yamaeda]

Strange. The Sort 2Darray.vim is ~380k while the Shuffle1DArray is only 3k code.

[Kyle97330 · Accepted solution]

The first thing I would note is most of that extra stuff will be compiled out if you build an EXE (with debug off) so if you're always doing that, you don't need to worry about performance unless you use it so much the excess load times or RAM usage is a problem.

Other than that, there are workarounds:

Workaround #1:

If you don't need to do the "fancy sort" (i.e. the one that sorts classes), just replace the VIM with the primitive.  The primitive is not on the palettes in LV2021 any more, but you can find it in one of the 3 frames of the structure inside the VIM, and copy-paste it out to your main VI.  This removes the entire overhead.

Workaround #2:

If you do need the "fancy sort", put down the VI, wire it up first (important!) and use the right-click option on it to either "Replace with SubVI contents" (will add a large diagram to your main VI temporarily) or "Convert Instance VI to standard VI" (which will make a new subVI that you have to save somewhere in your project, but can re-use other times you need to sort the same data type).  Then go to the new code (either on your diagram or in the subVI, whichever you picked), find the frame in the structure that says "Accepted" and select that one, then right-click the structure to remove it (and therefore all of the other frames).  This new code will be about 25% of the previous one's size (~160K) so it's still large, but much more manageable.

[Kyle97330]

Also if you want the old primitive back on your palette, I've attached a modified array.mnu file to this post.  It's the default one from 2021 32-bit with the old "Sort 1D array" function added, so if you're on a different version then it may not work.  I don't know how version-specific the menu files are.

[crossrulz]

---

@Kyle97330 wrote:

Workaround #1:

If you don't need to do the "fancy sort" (i.e. the one that sorts classes), just replace the VIM with the primitive.  The primitive is not on the palettes in LV2021 any more, but you can find it in one of the 3 frames of the structure inside the VIM, and copy-paste it out to your main VI.  This removes the entire overhead.

---

The primitive was added back to the palettes in LabVIEW 2021 SP1 and is still there in 2022 Q3.  So it is only missing in LabVIEW 2021 non-SP1.

[Dataflow_G]

Any time a malleable VI is called, a copy of that vim is embedded in the calling VI. This is known as an instance VI, and is given a random GUID based name. The instance VI is compiled using the types wired to the original vim. If you have a VI which calls the same vim twice, the vim will be converted to an instance VI and embedded twice in that VI. This can cause a VI's size to grow very large. For example here's a VI which calls 20 malleable VIs, and sits at almost 6MB on disk, even though the code size is small (it also takes an age to open):

If the malleable VI is calling another vim, which then calls one or more vims, then the size can grow exponentially as each instance VI contains it's own instance VIs. Combined with the GUID naming, you can get some very cryptic call chains:

You can convert instance VIs to regular VIs (right-click->Convert Instance VI to Standard VI) which will reduce the calling VI's size, but then you lose the benefit of the malleable VI.

[Basjong53]

---

@santo_13 wrote:

For the latter part, all VIM are inlined into the caller, so, it partially makes sense that the caller size will increase.

---

That seems reasonable. Thanks you.

---

@Kyle97330 wrote:

The first thing I would note is most of that extra stuff will be compiled out if you build an EXE (with debug off) so if you're always doing that, you don't need to worry about performance unless you use it so much the excess load times or RAM usage is a problem.

Other than that, there are workarounds:

Workaround #1:

If you don't need to do the "fancy sort" (i.e. the one that sorts classes), just replace the VIM with the primitive.  The primitive is not on the palettes in LV2021 any more, but you can find it in one of the 3 frames of the structure inside the VIM, and copy-paste it out to your main VI.  This removes the entire overhead.

---

Yeah, I just needed to sort a numeric array. I have the only version of LabVIEW that doesn't have the "Sort 1D Array" primitive on the quick-drop...