Showing results for 
Search instead for 
Did you mean: 

Memory Optimization LabVIEW

Go to solution

Hello Everyone,


Project Point Consideration, I will Interface 6 DMM,2DSO,1PLC,1Aurdino Board. All are Run inter process communication.


All are Interface With Ethernet, Only Arduino Its USB.  


For test performed 200Hr, In that Test Data Logging, Control & Monitoring  Continuously. Design Architecture Producer consumer.


Which Factor I Consider Before Development? I am Focusing On Memory Optimization For Code and PC.  

0 Kudos
Message 1 of 7

Hi Rupesh,


@rupesh.v wrote:

Which Factor I Consider Before Development? I am Focusing On Memory Optimization For Code and PC.  

Why do you focus on "memory optimization for code and PC"?

Why don't you focus on a well-defined program architecture and good documentation of the whole code?

Best regards,

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 2 of 7

“Premature optimization is the root of all evil” is a famous saying among software developers.


Its source is credited to Donald Knuth


Start coding. and start small. 


This is called "agile developing", your approach is obsolete

0 Kudos
Message 3 of 7
Accepted by rupesh.v

Your definitely barking up the wrong tree here. 


You have a fairly complex multi-device setup here. Even a seasoned programmer will have a nice challenge with such a setup. From the sound of it you aren't exactly very experienced in writing such applications and maybe also not with LabVIEW.


Starting to worry about memory optimization before you have even setup more than a very rough white board drawing is similar to starting to worry about the color of your blinds before you have even made a hole in the ground to start building your house.


The premature optimization remark attributed to Donald Knuth is definitely at its place here. Although to be honest here, this famous quote is actually more likely by Sir Tony Hoare (but was then popularized by Donald Knuth). And contrary to some people who quote it, it doesn't mean that thoughts about optimization shouldn't be part of the entire design process, rather than an afterthought (that never happens at the end since "it is working now and keep your hands of it"). But there are optimizations that make sense, and some that are just hot air, and others that are counterproductive. In order to make a decision to what category something belongs to you have to make measurements. But you can't measure performance of a fuzzy architectural idea in your head. For that you need real code that you can tweak to see how it behaves and if your gut feeling about what will be more optimal actually holds any merits. More often than not it doesn't. The performance gain will turn out to be minimal and sometimes simply negative despite your best guess.


But premature optimization is often a sign of avoiding behaviour. The task at hand seems to taunting, so lets start concentrating on a tiny little detail and make it perfect (which of course can't be done) and then we have an excuse why the project didn't get anywhere.


At this stage you have nothing to even think about optimization. Start with writing code to communicate with these devices. Then try to combine each piece into a bigger picture. At this stage you then have real code to look at and consider what performance and memory optimizations will have any merits and what will be simply eye candy without much effect.

Rolf Kalbermatter
Averna BV
Message 4 of 7

Hi GerdW,


Thanks for Reply


Why don't you focus on a well-defined program architecture and good documentation of the whole code?


Yes, I will Definitely Follow This Instruction.



0 Kudos
Message 5 of 7



Thank you for Suggestion. It is Helpful For Us




0 Kudos
Message 6 of 7

The bigger context of that quote about premature optimization is summarized here:


I've always thought this quote has all too often led software designers into serious mistakes because it has been applied to a different problem domain to what was intended. The full version of the quote is "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." and I agree with this. It's usually not worth spending a lot of time micro-optimizing code before it's obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems. An inexperienced developer will not bother, misguidedly believing that a bit of fine tuning at a later stage will fix any problems.

There are a few important things in here.


- First, micro optimization is almost never justified. Performance bottlenecks are almost always the main reason why an application feels and behaves sluggish. Speeding up an algorithme that is not called umptien million times, even if you get it to run 10% faster, has usually no or only a barely measurable effect on the performance of the whole application.


- Architectural considerations should be taken into account from the start, but that requires experience and experience you only get by doing things, not mulling over them.


- But before you can really start to worry about architecture you should have at least some working code for the control of your different instruments. There you can see how they behave, if they are slow, fast, have special measurement modes that may take long times to execute, or may actually pose other challenges such as undocumented protocols etc. It would be a bit unfortunate to have designed a nice, well performing architecture only to find out that the devices you had planned to use can't be controlled in the way you planned, and that your architecture needs to be redesigned because of that.


For devices that have little to no delay, you can consider adding them inline with other operations. For devices that require sometimes lengthy sequences of operation you will seriously need to consider to put them into their own "task" and then use some messaging scheme such as the Consumer/Producer architecture to connect them with the rest of your application. But setting up this Consumer/Producer architecture without some devices to actually put in and test it with is maybe a nice classroom exercise but won't help you get your application finished.

Rolf Kalbermatter
Averna BV
Message 7 of 7