05-10-2016 08:35 AM
05-10-2016 09:41 AM - edited 05-10-2016 09:44 AM
Maybe you could use SGL. Most of the linear algebra in LabVIEW is however DBL only.
Are you using stock functions or are you doing all your own things from simple math primitives? If so, why?
Any imrpovement would be hard to predict. You ned to benchmark. You still hanve;t really told us what the operations are. Are they all carefully crafted to operate in-place or are you constantly doimg new memory allocations?
05-10-2016 10:10 AM
05-10-2016 10:13 AM
05-10-2016 10:22 AM - edited 05-10-2016 10:23 AM
Because the input connector has a defined datatype and a coercion occurs, meaning LabVIEW needs to create a new copy in the new representation. This can be expensive. If you want the subVI to be SGL, you need to write it in SGL.
If you want a subVIs that should automatically adapt to DBL vs SGL, you need to make it polymorphic, which involves additional efforts.
05-10-2016 10:30 AM
05-10-2016 10:35 AM
I really don't want to send you on a useless witch hunt, because overall code design will be much more important than datatype alone.
It would really help if we could see some code. Often a redesign of the code with inplaceness in mind can give you orders of magnitude improvements while changing datatyes can only give you a marginal improvement. Have you looked in the linear algebra palette to see if there are existing functions that you could use. (If you have the MASM toolkit, there are even parallelized versions.) Look for memory allocation dots and coercion dots.
If you constantly go in an out of subVIs, try to inline them. At least make sure debugging is disabled and their front panel not open or in memory when testing speed. Avoid all property nodes.
If you are trying to improve performance, as a first step you need to build a relable testing harness to gauge the effect of code changes and compare versions. This is often not trivial. We can help.
05-10-2016 12:03 PM
This thread has moved away from "stop and quit labivew", but I wanted to share a function I have for when I really want to stop and quit LabVIEW.
We have an application-building app that runs as a service (under Windows). Note the application builder only runs in the development environment. By running as a service, we can run four instances of the dev env at the same time on a four-core machine and keep all the cores loaded up during a build. The build-bot checks out the sources code to a local directory, runs some tests, builds the application and installer, and stores the build products. Then it quits, because it will be automatically restarted by the service manager. On startup, it starts working on the next build requested. We use FireDaemon as our service runner.
But if LabView throws up a dialog box during exit, the code is wedged, as Windows Services do not support a user interface. The instance just sits there, typically using 1-2 GB of ram, stuck at the SAVE CHANGES? dialog box that nobody can click on. (Amazingly, the built-in "exit" function doesn't bypass this dialog box, even if "quit" is true.) The only thing I have found that really works is the sledgehammer solution below, which uses the WinAPI to exit unconditionally.
Note this is not want you want for interrupting a long-running calculation on a million rows! Crossrulz' method of testing a notifier (or notifier refnum, that's how we do it) once in while in a breakable for loop is the best way to do that. (Or refactor to work with a million item queue one at a time, which is easy and suprisingly fast if the elements are independent.)
-Rob
.
05-10-2016 12:46 PM
I don't think he want to stop LabVIEW, just some lenghty calculation inside a subVI while keeping the main running. (If I understand right).
05-10-2016 01:48 PM