How can I speed up the execution of my VI?

[Helper]

HI,
I have a pretty complicated VI which revolves around one big picture control on the front panel, on which I display all sorts of data, most coming from one big global array. As I run the VI it becomes exceptionaly slow in a hurry and does not react to mouse clicks for 5-10 seconds. I have read up and down this website especially the optimizing performance section, I was just hoping someone could tell me what are the really big problems with a block diagram that are the cause of this lagging?

[CraigGraham]

You probably have to split your program into several functional elements
that communicate with each other, rather than simply one sequential list of
operations continuously looping.

So one element checks for user input say every 100ms, responds to it and
sends messages to the other functional elements which then act on the
change. If you use queues to communicate between, then you can send "high
priority" events by placing them at the front of the queue.

Alternatively your problem may be far simpler than I imagine. Check your
system memory use as the program runs; if you're running away allocating
lots of memory all the time then it'll hammer the machine and all will grind
to a halt. If system memory use continuously increases and all other
applications also
get hit and respond slowly, then you'll have to look
through and see where memory is being accumulated.

Helper wrote in message
news:50650000000800000067340000-1005954886000@exchange.ni.com...
> HI,
> I have a pretty complicated VI which revolves around one big picture
> control on the front panel, on which I display all sorts of data, most
> coming from one big global array. As I run the VI it becomes
> exceptionaly slow in a hurry and does not react to mouse clicks for
> 5-10 seconds. I have read up and down this website especially the
> optimizing performance section, I was just hoping someone could tell
> me what are the really big problems with a block diagram that are the
> cause of this lagging?

[Greg_McKaskle2]

> I have a pretty complicated VI which revolves around one big picture
> control on the front panel, on which I display all sorts of data, most
> coming from one big global array. As I run the VI it becomes
> exceptionaly slow in a hurry and does not react to mouse clicks for
> 5-10 seconds. I have read up and down this website especially the
> optimizing performance section, I was just hoping someone could tell
> me what are the really big problems with a block diagram that are the
> cause of this lagging?
>

Are you using lots of locals? I've seen diagrams that read, append
and update the picture control all over the place. You should really
avoid multiple updates to controls that take time to update.


Of course, instead of guessing what is taking th
e time, what you really
want to do is to use the profiler to measure where the time is being
spent. You can separate out the time of various subVIs from your
diagram from the panel updates. That will help you focus your code
changes on the big things that will make a difference. Open the profile
window, Start it, then run the VI for a bit. Turn off the profiler or
snapshot it and let the results guide you. You probably want to turn on
the Timing Details to get a better view of the UI cost.

Another thing to keep in mind is to use a wait function to avoid reading
the panel controls as often. Even sleeping for ten millisecond will
make a huge difference compared to no sleep at all.

Greg McKaskle

[Helper]

HI,
YOu are right I am updating the picture in a multitude of places...many of which involve for loops with shift registers.. Is there any way to store say and array of x,y points and then add them to the picture all at once or do I have to use the for loop / shift register technique?

[Dennis_Knutson]

It's hard to say without looking at your program but if you use local variables and the build array function, that might account for the slow down. Each local creates a copy of the array and each build array function causes LabVIEW to allocate more and more memory for the storage and any processing of large arrays is going to take longer. Can you set the size of the array and use the Replace Array Subset instead?

[Greg_McKaskle2]

> YOu are right I am updating the picture in a multitude of
> places...many of which involve for loops with shift registers.. Is
> there any way to store say and array of x,y points and then add them
> to the picture all at once or do I have to use the for loop / shift
> register technique?



I'm not sure what the diagram looks like. You can add to the picture
data without writing to the indicator. Write to the indicator fewer
times and instead use the picture in to string together the picture VIs
to build the picture. To answer the other question, if what you are
going to add is a bunch of lines, then the polyline routine will do what
you want. The graph examples and utiltity VIs for things like the polar
plot are things to look at
that are doing similar jobs.

Greg McKaskle

[AIR]

Hi,

Does any of the for loops have shift registers with arrays in them? Do you
add elements to it?

If so, the shift register must be wired from the outside with an empty
array, otherwise the shift register will grow and grow, until the program
will get slower and slower.

Regards,

Wiebe.


"Helper" wrote in message
news:506500000005000000D4520000-1005954886000@exchange.ni.com...
> HI,
> YOu are right I am updating the picture in a multitude of
> places...many of which involve for loops with shift registers.. Is
> there any way to store say and array of x,y points and then add them
> to the picture all at once or do I have to use the for loop / shift
> register technique?

[CraigGraham]

No, the shift register has to be fed from the outside with a *full* array,
pre-initialised to as many elements as needed in the program. Adding data to
the array within the program should then be done using "replace array
element".

AIR wrote in message news:9v4qhe$e4b$1@news1.xs4all.nl...
> Hi,
>
> Does any of the for loops have shift registers with arrays in them? Do you
> add elements to it?
>
> If so, the shift register must be wired from the outside with an empty
> array, otherwise the shift register will grow and grow, until the program
> will get slower and slower.