Slow load time for built application

[falkpl]

I have built an application which has been developed in LV 7.0 and uses daqMX 7.3 which works fine in both the built and source forms.  The application is somewhat large, with over 100 of my own vis and a few hundred total vi in its hierarchy.  When loading the executable it takes 10-15 seconds to see anything on the screen, while the source (non built) system loads in under 5 seconds.  Why is the built application so slow to load.  I even implemented a splash screen which is a simple vi above the main hoping that would solve my problems.  Has any one experienced problems with the load time of built applications in LV7.0.  is this the time to load the run-time engine?  Are there any fixes to this.  I plan to distribute this system for testing at remote sites with some prototype hardware in the next month and don't want to discourage the user.  The load time is the first impression of my application, and we all know how much first impressions count.  Any advice is appreciated.

Paul

[DFGray]

You are correct that there is some time required to load the LV run-time engine (LVRTE).  However, it should not be 15 seconds, but closer to five.  It sounds like you are waiting on loading all of DAQmx.  Some things you can do to help.

1. Create an independent splash screen.  You already have a splash screen, but you need to make sure that the main VI is called dynamically (using VI server) and is not just a subVI in the splash screen.  This way, the only load time you will see before the splash screen comes up is the LVRTE.  This should be about five seconds for LV7.0 (or less, depending upon your computer hardware)
2. Consider putting some sort of loading indicator on your splash screen.  One way to do this is to use a Pict Ring control and load the the images with some animation.  Run the animation with a timed or while loop while loading the main VI (works great for animated lightning since you can randomly pick a frame to display).  Alternately, drop an animated GIF on the front panel and show/hide it using VI server at the appropriate times.
3. If you are really into pain, you can dynamically call all DAQmx VIs so that none of them load until actually needed.  Note that the user will see this as a delay the first time they run an acquisition.
4. Build your application into a single executable.  LabVIEW executables load fastest from a single file.  If you use multiple LLBs, it will slow things down.
   

Note that reducing the size of your application will not help much.  A 20MByte app (500 - 1000 VIs) loads in 1-2 seconds on a 650MHz Pentium III era machine, provided it is all in one file.  This is after the run-time engine starts and any libraries (i.e. DAQmx) have loaded.

Good luck.  Let me know if you need any more information.

[falkpl]

Thanks, I will try your suggestions, My intuition was that every vi is loading before I see the splash screen, so dynamically loading the main vi (one level below the splash screen) should speed things up.  Is there any hit in performance with dynamically loading the main vi vs calling it as a subvi, I can not compromise performance since this is an application for monitoring radiation in real-time for radio-therapy treatments (just a prototype at an experimental stage).  The application works great except this load time.  One other thing I considered is using a batch file to load a splash picture, then call the application then close the splash picture after some delay, this is not very good fix but might work.  I will try to dynamically load the main vi which contains almost the entire code dynamically, then use a progress bar to monitor labviews number of vis loaded divided by the total number in the main application which should show the user that the program is actually loading.

Paul

[DFGray]

Once the main VI is up and running, it doesn't matter whether it was called dynamically or statically.  Performance will be identical.  Load time will be close to the same whether you load dynamically or statically, but with a loader VI/splash screen, you can at least get a panel up fast and let the user know something is happening.  In the splash screen, I usually open a reference to the main VI, then run it using the Run VI method with Wait until done set to False and Auto Dispose Ref set to True.  The splash screen then exits after the main VI has launched.  One thing to beware of - the LabVIEW run time engine constantly checks to ensure at least one top level VI is visible.  You have to be absolutely sure the main VI is showing its front panel before you exit the splash screen or LabVIEW will exit.  You can do this by directly querying the Front Panel Window->Open property of the main VI, or you can use semaphores/notifiers to signal between the two VIs.  I have used both successfully.

I like your idea of the loading progress bar.  However, I am not sure how well it will work, since a large portion of your load time is loading DAQmx.  You might be able to do something similar using memory metrics that would work better.

[falkpl]

DFGray,

Thanks, dynamic loading solved most of the problem, now the splash screen loads in 2-3 seconds instead of 15 seconds, then the vi waits while loading the code for an additional 10 seconds.  This load still is very slow (I think it must be daqMX functions) but now there is at least a splash screen showing letting the user know that the application is loading.  I did try to implement the progress bar but it will not work, the load process seems to be hogging the PC's resources and the progress bar doesn't show.  I even moved the progress to its own loop, but there is no context switching between threads.  I don't see any way around it but I might paste an animated GIF on the splash screen to simulate a loading sequence, like sands through the hourglass (no I don't watch soap operas).  Any way thanks again. This solved enough of my problem to get me going.  When I have I really good solution, I will try to make it a template so I can share this with the community.  A splash screen should be a useful option for any application.

Paul

[tst]

Paul, if I remember correctly, one of the OpenGOOP tutorials (in the old OpenG site which is still up) was about making a splash screen\progress bar. You may wish to have a look there.

[falkpl]

I will look on openG for the splash screen tutorial.  Maybe LV 8.0 will have a auto-splash screen generator in the app-builder

[falkpl]

I will look on openG for the splash screen tutorial.  Maybe LV 8.0 will have a auto-splash screen generator in the app-builder

[tst]

OK, I did a quick search to make sure I remembered correctly and there is a presentation with audio and 3 examples, one of which is a progress dialog. It can be found here.

Edit - an important point I remembered is that  the examples use one of the old versions of OpenG. There should be a utility in the same site (probably the downloads section) to convert projects with old OpenG VIs to new ones. It worked fine for me.

Message Edited by tst on 08-26-2005 12:15 AM

[falkpl]

Thanks, I will check it out.