VIs run much slower in LVLIBP

[CAPTIC_LA]

Hi all,

Recently, I split my Vision application (LabVIEW 2016 with NI Vision Module acquisition and image processing) in portions of modular code to be reused, and placed these VIs in several packaged libraries.

But I finally discovered that my "new" application (using packaged libraries) runs much slower than the previous version (with all VIs in the same project).

I made a sample in attachment which only runs a VI computing a distance between 2 points, in parallel loops. 

You could see that the version in LVLIBP is up to 20 times slower!

Can anyone tell me if this if "normal" ? How can we have both modular and fast applications?

Thanks a lot for your help

Lionel

[Jun']

Hi Lionel,

I cannot execute your code because you are using non-native G functions I don't have installed. I started replacing with the native functions but then the VI called in the subVI pointed as VI in LVLibp also cannot be found so I stopped making modifcations.

As a more general feedback, lvlibp have indeed good use case but they also have caveats. Do you know of this document?

Caveats and Recommendations for Packed Project Libraries

Thanks

Junior

[LucianM]

I edited the files to use only native functions and cleaned it a little and I saw the same behavior as OP reported: calling the VI from lvlibp is much slower.

Attachment files are saved with LabVIEW 2018. If you open with a newer version, you need to rebuild the lvlibp using the Test Lib.lvproj.

[CAPTIC_LA · Accepted solution]

Thanks LucianM and Jun for your messages.

@Jun : Yes I already read this document, that helped on other issues

@LucianM : Thanks for reformatting the code

Actually, "NI technical support" found a part of the solution : in the properties of the build of the Packaged lib you have to uncheck "Callers adapt at runtime to Exported VI connector pane state" and rebuild the lib

But this is not enough : if you just run again the caller VI (main project) it's still running slowly . "NI technical support" suggested to replace manually in the caller VIs all the calls to the VIs of the lib (and it works), but this is impossible to do in a project of several thousand VIs.

I tried a "mass compile" but it didn't work (?!). At the end, what works is "Ctrl+Shift+Run" (force recompile) with all VIs of the main project loaded in memory (opening the main VI and opening directly other VIs if dynamically loaded).

At the end, what I don't really understand is the relation between this option and the execution time, because even if you leave this option checked, and you change the connector panel of a VI in the lib, you still have to reload and recompile the caller VIs in the main project, so it seams to me that callers VIs never adapt to connector panel change. So at the end, to me it would be better to uncheck this option by default...

[crossrulz]

---

@CAPTIC_LA wrote:

I tried a "mass compile" but it didn't work (?!). At the end, what works is "Ctrl+Shift+Run" (force recompile) with all VIs of the main project loaded in memory (opening the main VI and opening directly other VIs if dynamically loaded).

---

Along the same lines, you should probably also clear out your compiled object cache (Tools->Advanced->Clear Compiled Object Cache).  Many issues seem to be fixed by clearing this out every once in awhile.