"Dawn Davis" wrote in message
news:3a8bdbd1@newsgroups.ni.com...
> window is much too slow. If i put both windoes in the bacground, they
seem
> to run at the same speed, but it still is much slower than on the Apple.
> What can I do to optimize the speed of the applications?
I've been fighting with application speed problems myself for the past
little bit. I love to see discussion of this, because the NI devzone has
very few suggestions. Lemme throw out a few general thoughts on ways to
improve speed:
* Check the VI Options (edit a VI, right click the icon in top right corner)
and there's a tab for execution parameters. Read up on the options, they
adjust the execution priorities. This could solve some of your problems. In
my case, it didn't help a lot because I wanted to adjust priorities among
loops in my event-handler, not of subVIs.
* Parallellize your application by putting seperate events into seperate
while-loops. In most cases serializing work is a real slow thing. Labview
can decide when no data or control hazards exist, whenever possible it will
execute stuff in parallel. Be forewarned, in many situations globals and
locals will create all kinds of unforseen data dependancies between parallel
while-loops. Be conscious of the underlying multitasking, Mac Unix and
Windows handle things differently as described on the NI website.
* Spinning while-loops make REAL SLOW code. The timer-icon is one solution
but not a very good one. I saw an order of magnitude speed increase changing
my code to use the notify VI's set to never timeout. If this is right in
your situation, by all means switch! The polling scheme serializes things
too much. Event-messaging will let the system execute important things while
other sections wait.
* Unforseen factors will change things, especially priority for the
foreground application. One solution might be to change to the GOOP model
(www.ni.com/goop). If written correctly, it should be easy to access each
instance of the program as a seperate object. That way you'd never have a
second app in the background, it would run out of a single application. This
will also help eliminate tricky globals which helps create parallelism. The
goop vi's really don't add much overhead, in my experience.
* Modify algorithms to be more efficient. Consider hiring some college
undergrad fresh out of an algorithms course to calculate your Big-O
complexity on algorithms. Fix those problems with better data structures!
Labview will re-size arrays and structures but this is very slow, always
prevent this from happening by initializing the array and not resizing. Get
the professional version which has the VI profiler to check what's slow.
Amdahl's law, make the common case fast!
* Look at the machine you're running it on. Labview is memory and processor
hungry compared to something like C++. My company's app is pretty large and
runs ok on a Celeron P400 with 128 meg of ram. There prob will be problems
if the computer is memory starved, possibly the case since you said two
copies are running at once.
* Move to 6i for any large app. The front-panel control reference is
absolutely invaluable for complex programs. I cannot believe people could
work without control reference.
* Some events are just dog-slow, for example polling the mouse properties in
a picture indicator, or polling a front-panel control to see if it's changed
since the last loop iteration. Running these in a lower priority loop might
help, but I've never found a good solution.
That's just my quick thoughts on the issue. Email me or post follow ups, I'm
always interested in this topic.
-joey