Application executable file size - When is it too big?

[mikeporter]

Actuially, I did mention poor design and implementation - and I would agree that this is where anybody who is concerned about code size should start their investigation. However, it's not just poor or subpar practices. Something that could be a very good thing in one context can be very bad in another.

Case in point: Say that whatever reason you have to have the build setting turned off that removes unused library members. If you use even one math function - like the Mean VI - and you will compile into your code the entire basic analysis library (all 12M of it).

You also need a good dose of what I call heads-up programming practices.

Mike...

[dacad]

Have been a LV user for 4-5 years and have built some pretty extensive apps. Extensive database read/write, datalog file storage, SPC/Control charting with the DSC module, and I have a pretty good knack for experimenting and figuring stuff out and also reading the examples and using the forum.  I already got the CLAD earlier this month and am going to take the CLD in Feb or March.  Have started looking at the sample exams for that and they are much simpler than what I have been doing for real.  Only going through the cert process now due to desire to add to resume.

As far as my build spec, I indeed select to not include uneeded library files and anything else I can see to exclude that I know I don't need.

I have always been under the impression that when most major apps run, they run with a core exe along with some (many) other dll's and/or libraries and stuff and then load the other only when needed.   Take MS Word for example,  A huge application overall and the exe (Office 14) is still less than 2 meg but there are tons of other files that have to be available.  This allows only the needed items to be active in memory.

If I could determine which LV functions are not used often in my code, I could isolate those into separate libraries or dll's and not include them in my exe.  The actual exe should then run with much less overhead.

This is just what I feel should be a logical approach but I'm not a coding and compiling expert by any means. And I don't want to be, with the exception of LV apps.

Still looking to learn

Doug

[mikeporter]

Excellent point, Doug:

There is no law that an entire application even needs to be in a single executable. It is very possible to architect a system such that iit consists of a cluster of independent executables that communicate via VI Server - or some other protocol - and together do what needs to be done. The advantage is that only the pieces needing updates need ever be changed.

I wish to suggest that an appropriate metaphor is that of a community of interacting entities. ... The problem of programming is the problem of designing this community: Who are its members? How do they interact? What goes inside each one? - Lynn A Stein, "Challenging the Computational Metaphor:Implications for How We Think", 1990

Food for thought.

Mike...

[Norbert_B]

Doug (and all),

building a monolithic stand-alone EXE is nowadays considered as bad practice. So we can concur that "splitting the complete application apart into well-defined, encapsulated modules" is a key point to get a good architecture and "easy to deploy" application.

I for myself have not yet written really large LV applications, since my job profile doesn't comprise this. But for my small applications (more example kind of stuff), i never encountered the EXE to be larger in size than the sum of my self-written components.

That being said, you should take a close look into Mike's (and others) suggestion about the build script settings. I think the hint with the libraries (from vi.lib, instr.lib and user.lib) is really valuable.

As it comes to streamlining the EXE into a more modular application, you might want to look into "Plugin Architecture".

That technique often points to LVOOP, maybe including Packed Project Libraries. I think these are the keywords you are hunting for to improve your LV development skills.

Here some links:

LVOOP - The decisions behind the design

Object Oriented Design Patterns Technical Manual and Exercises

To PPL or not to PPL

Packed Project Library Pitfalls

hope this helps,

Norbert

[Mark_Yedinak]

While I completely agree with many of the comments above regarding more modular packages to make distributing applications easier I did want to point out the obvious. Separating the code into smaller packages does not alleviate the problem with the initial distribution still being fairly sizable. The initial distribution will still need to distribute all the necessary packages and runtime engines required for the application. Updates and feature enhancements will be much easier but the first time install still needs everything.

[dacad]

Will certainly look into these topcis and see what I can pluck out of them.

Thanks Norbert for giving me at least a direction to start looking

Doug