LabVIEW
When does LabVIEW compile a VI?
You don't have to worry about compiling issues, LabVIEW always runs compiled. (Mass compile is a differenet tool and is usually used to convert a hierarchy of folders containing VIs to a new version. It's more a mass-convert, while of course it includes a recompile as part of the process).
The answer to your issues are elswhere. Here are some of my favorites, but I'm sure others will have more to add:
(1) Programming skills: Have a look at e.g. the results of the first LabVIEW Zone Coding challenge. An inefficiently coded solution took 14 seconds to complete the taks, while the top solutions did the same in about 60ms. There are many ways to code a certain task and some ar
e significantly faster than others. Carefully check for unecessary data copies and use the profiling tools to see where most of the time is spent. Be especially picky for the innermost loops of critical code sections, here it might be worth to flatten subVIs out to the main diagram to avoid the small subVI call panalty. Have a look at the LabVIEW Performance and Memory Management
application note for some starting points. If in doubt, code alternate version, then pit them against each other in a speed competition.
(2) Tweaking of VI settings: Disabling debugging, setting priorities (e.g. subVIs to "subroutine"), etc. can make a difference.
(3) Avoid unecessary tasks: Don't waste CPU resources to constantly redraw indicators, graphs, etc. make sure that these things occur sparingly and not deep inside loops. Avoid local variables, global variables, property
nodes, etc.
The answer to your issues are elswhere. Here are some of my favorites, but I'm sure others will have more to add:
(1) Programming skills: Have a look at e.g. the results of the first LabVIEW Zone Coding challenge. An inefficiently coded solution took 14 seconds to complete the taks, while the top solutions did the same in about 60ms. There are many ways to code a certain task and some ar
e significantly faster than others. Carefully check for unecessary data copies and use the profiling tools to see where most of the time is spent. Be especially picky for the innermost loops of critical code sections, here it might be worth to flatten subVIs out to the main diagram to avoid the small subVI call panalty. Have a look at the LabVIEW Performance and Memory Management
application note for some starting points. If in doubt, code alternate version, then pit them against each other in a speed competition.
(2) Tweaking of VI settings: Disabling debugging, setting priorities (e.g. subVIs to "subroutine"), etc. can make a difference.
(3) Avoid unecessary tasks: Don't waste CPU resources to constantly redraw indicators, graphs, etc. make sure that these things occur sparingly and not deep inside loops. Avoid local variables, global variables, property
nodes, etc.
