Pack the existing LabVIEW functions to Packed Project Libraries to speed up EVERYTHING

[PrimaryKey]

I was thinking that defining packed project libraries as the source of VIs used by the LabVIEW enviroment would speed up everything ex. loading LabVIEW, loading palettes linking dependencies, building executables etc. + solve linking dependecies conflicts.

The thing that we could do is just add the packed project library for the standard LabVIEW functions as the base of the palettes, but since we want users to be able to see what's inside we would still leave the VIs in the same folders - this way the user would be able to choose if he wants to use the packed versions or the versions from the disk - unpacked. 

This way only the ones with a specific unpacked instance would have to be loaded as single VIs, and we would have everything nice and clean.

Tell me what you think.

[CMal]

I think there would be a lot of cases where this would actually increase load, build, and deploy time.  Many applications only use a small subset of the VIs from any one of the built-in LabVIEW libraries.  Changing these libraries to packed libraries would force the entire library to be loaded into memory, even if only one of the member VIs is actually used.  I haven't done any benchmarking on this, but I expect that using packed libraries would only improve performance in cases where nearly all of the VIs in a given library are already being used.  I also worry that there would be compatibility issues if each library were shipped as both lvlib and lvlibp.

[AristosQueue (NI)]

There are many many downsides to this idea. The showstoppers are a) that customers would no longer be able to debug into our VIs and b) they would not be able to duplicate our code and modify it for their own uses. Smaller issues include: Inlining VIs would no longer inline fully. VIs could no longer recompile for service pack changes. Significant bloat to every built application that uses just one VI in a packed project library because it would depend upon the whole library. A significant increase in the number of EXEs that could no longer be a single file distribution (because they'd depend upon the PPL). I'm sure there are more. Shipping both the packed and unpacked versions just increases the chances of cross-linking and other build problems. It also means there's a chance of the two drifting out of sync with each other.

[Darren]

From AristosQueue: "There are many many downsides to this idea. The showstoppers are a) that customers would no longer be able to debug into our VIs and b) they would not be able to duplicate our code and modify it for their own uses. Smaller issues include: Inlining VIs would no longer inline fully. VIs could no longer recompile for service pack changes. Significant bloat to every built application that uses just one VI in a packed project library because it would depend upon the whole library. A significant increase in the number of EXEs that could no longer be a single file distribution (because they'd depend upon the PPL). I'm sure there are more."