Improving load times in Linux LabVIEW executable

[Dennisvr]

I'm looking for (simple) ways to improve the loading times in a Linux LabVIEW executable. We're using a low performance, low cost CPU board, and loading times are terrible. The CPU is capable of doing everything after the application is loaded, but takes forever to get there.

One of the problems is the size of the executable, that grows everytime you just look at it. Are there ways to create smaller executables? It runs from a Compact Flash card, which is ofcourse much slower than hard disk.

Another problem is a dynamic vi, that is started for every TCP connection that connects to the application. It takes a long time to load, and connecting too fast can even effectively hang up the system. Starting a handler task takes about half a second, up to a few seconds for the first task.

We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.

[rolfk]

---

@Dennisvr wrote:

I'm looking for (simple) ways to improve the loading times in a Linux LabVIEW executable. We're using a low performance, low cost CPU board, and loading times are terrible. The CPU is capable of doing everything after the application is loaded, but takes forever to get there.

One of the problems is the size of the executable, that grows everytime you just look at it. Are there ways to create smaller executables? It runs from a Compact Flash card, which is ofcourse much slower than hard disk.

Another problem is a dynamic vi, that is started for every TCP connection that connects to the application. It takes a long time to load, and connecting too fast can even effectively hang up the system. Starting a handler task takes about half a second, up to a few seconds for the first task.

We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.

---

I'm not sure about the first part of your question. LabVIEW is highly binary and does a lot of memory allocations before even one VI is ready to be started. So maybe the memory manager is a problem. Another issue is that the Macintosh like resource file format that is used by LabVIEW to store its VIs etc. results in lots and lots of individual disk accesses with a rther random like character inside a single file. So if you can configure the read caching of your disk to use more memory this may significantly increase the speed of loading LabVIEW VIs or applications.

And finally spawning VIs through VI server is a rather costly operation especially on low resoruce systems. A VI is more like an executable in many ways as far as resource consumption is concerned rather than a thread. A much better way would be to avoid spawning subVIs altogether and implement a queued TCP/IP server similar to the Date Time Server example. It is a little extra work to work with this shift register architecture but it will not have the issues of long load times for every new TCP/IP connection coming in.

Rolf Kalbermatter

Message Edited by rolfk on 03-07-2006 06:33 PM

[Dennisvr]

That's exactly what we're seeing. It takes almost 2 minutes before the application is loaded, after that, when it starts executing, it's up and running in seconds. And that's exactly what i want to improve. I'm not sure if I can improve caching. A lot faster compact flashes (read/write speed) are being sold now, so I might try one of those, to see the difference.

Would the loading time decrease if the size of the application decreases? Are there ways to generate smaller executables?

I liked the structure of the dynamic vi, because of possible blocking I/O in every client thread. If I were to make a sequencial (queued) server, I'd have to be careful not to block other clients. At the moment, after the vi has been started, performance is great. It's just getting there that's the problem. I did a test to measure the speed, i takes 2.5 seconds to get the first reply, an 15/16ms to get the second. When another client has already opened a connection, performance increases a bit: 0.8 seconds for the first and 15/16ms for the second.

However, at some time it's possible that 10s of clients connect. The problem when this happens is that the server gets lagged so much clients that already have a connection can lose it because of time-outs and start reconnecting too.

[KvZ]

Hi Dennisvr,

To improve startup time and load time of VI's you could try to first copy all files needed to a RAM disk, this way you would only need to access the slow flash disk once and then use the much faster RAM disk to load your executable. I'm no linux expert so I'm not sure if you could also get the LabVIEW Run-Time Engine to run from the RAM disk. This of course will require you to allocate part of your memory for this disk.

When building a executable most of the size reductions are already done for you, things like removing frontpanels, block diagrams and disabling debuging where possible. One section of a VI, the data area used for storing default control values and block diagram constats etc could become lardge when you have defaults values set for arrays, graphs, charts etc. or are using the same type of constants in your block diagram.

Regards,

Karsten 

[Dennisvr]

Thanx both for the reply by the way!

The ramdisk is a good option, it's quite easy to implement. However it didn't seem to matter very much, changes were hardly noticeable.

I looked at default values of variables some time ago, and didn't find anything special. It's worth another look though, it will take some time before I finish with this. I'll post results later.

Other suggestions are still welcome.

[Dennisvr]

I got a little further, and thought I'd let you know.

In stead of passing the variables through the front panel (as in the LabVIEW example), I tried using a queue. Performance is way up now! The first connection takes about 600ms, the second about 250ms. Less than one third of the original time. That means that I can handle 4 incoming connections per second. I also added a safety option, if more than 10 connections are pending, I close all pending connections. This way if the server lags at any time, it rids all the pending connections, which are doomed to be closed anyway, and starts over.

I'll take a look at executable size next. I seems that the program uses a lot of memory when loading. Is there an easy way to see what vi's cause this?