Reducing load time - half way to a plugin architecture

[MartinMcD]

Hello there,

This might be a silly question but here goes anyway...

I have a large modular data acquisition and sound & vibration analysis program. I have implemented it using the actor framework. I have ~5 main actors and then about 40 sub-actors, one for each analysis type.

This means my executable is about 40MB and takes a while to start up. All the sub-actors/dependencies are included because are set as 'always include' in the build spec. This is a pain as most of the time a user will only want to use a subset of the functionality - the program takes up more memory than it needs to.

To solve this I wanted to implement more of a plugin architecture according to this post https://decibel.ni.com/content/docs/DOC-19176 but got stuck doing so.

I was wondering if there is another alternative to a packed project library which would allow the sub-actors to exist in such a way that they are only loaded when they are needed. I need to include all dependencies in the build somewhere as not all users have LabVIEW on their machines.

Thank you for any pointers, hope this makes sense,

Martin

[asbo]

We have a product which used a plugin architecture before packed projects were cool. I'll try to remember to take a peek at it and see if there's any secrets I can share. If memory serves, though, the build for the product didn't include any plugins de facto, which means the file hierarchy was scanned to pick up plugins. It would be very simple to have a build for the base product, builds for each plugin, and an installer to wrap everything in one package for distribution, though.

[Aristos Queue]

You do not have to build packed project libraries at all. Just load from source files. I believe that easiest is to save without block diagrams into a .LLB file. Then you have just a single .LLB per class that you want to load, and your EXE can load from that, and without block diagrams, your code is sealed away from modification or inspection, just as it would be during compilation as EXE or packed library.

[PaulL]

I have to admit I'm not a big fan of the source files approach, although for certain use cases it might be fine. See this thread here (it's old, but the key points are there) for a discussion of the topic (http://lavag.org/topic/14212-how-to-call-a-plug-in-object-from-an-executable/page__fromsearch__1). My biggest (not only) concern (name collisions resulting in multiple files is another) is that it just seems weird to install source files (even without diagrams) as part of an installed application. Maybe this is more common than I realize?

[fabric]

I've found plenty of load-time benefit by loading my plugin classes (subactors) dynamically, but *without* packaging them as external libraries.

E.g create a subfolder in your project called "plugins" containing all your subactor libraries. Then just drop the plugins folder into the "Always Included" section of your build spec. Load as needed dynamically by path from "..myapp.exe\plugins\mysubactor..".

Provided you don't have any static links to your subactors in your main code then your app should load up much quicker. Only drawback is that you need to re-release the build if you change any single plugin, but often that is no problem in practice.

[MartinMcD]

Provided you don't have any static links to your subactors in your main code then your app should load up much quicker. Only drawback is that you need to re-release the build if you change any single plugin, but often that is no problem in practice.

Thanks everyone, I was a away for a bit and missed the replies to my question. I am going to progress with this option as it is really the quicker load time/less memory use that I'm looking for, I will just continue to roll out whole-program updates as fabric suggests.