Loop overhead ??

[Randall Miller]

My application is growing to dozens of vi's with multiple loops, each with a
delay. How can I determine the approximate number of loop activations per
second can be handled by the OS without it just thrashing between threads?
We're using a Pentium 3, 650mHz, 128MB, NT4/sp5.

Thanks, this is my first application under NT and the old rules-of-thumb aren't
always applicable.
Randall Miller

[Greg_McKaskle2]

> My application is growing to dozens of vi's with multiple loops, each with a
> delay. How can I determine the approximate number of loop activations per
> second can be handled by the OS without it just thrashing between threads?
> We're using a Pentium 3, 650mHz, 128MB, NT4/sp5.
>

You have several tools at your disposal. The best macro-level tool is the
Task manager. It will show the CPU utilization over time. Its one number
that easily gives you a feeling for how well behaved your application is.

If its not behaving well, then it does nothing to help find the culprit.
For that, use the built-in LV profiler. It will give you lots of data,
and is a bit harder to learn, but can help pinpoint runaway loops.

Lastly, you will need some estimates for timing. I'v
e seen applications
with thousands of parallel loops running that only take about 10% of the
CPU time. Any one loop adds somewhere around 50ns or so. That means that
a single empty loop can execute around 20 million iterations per second.
Actions placed in the loop will take additional time, but I'd say that your
interface loops with somewhere between 50ms or so of delay in them will
feel very responsive, will only execute 20 times per second. That means
that several thousand of these will use a small fraction of the CPU.
That leaves almost all of the time for computation, acquisition, and
display.

Unfortunately, if you leave a delay out of any of your loops, they will
be running at 100%. The CPU will likely be pegged, and the interface
will feel slugish. The profiler will quickly point out the VIs with
the offending loops.

Greg McKaskle