Why does menu speed program?

[GFDGreg]

Hi All,

I'm running a labview progam that does some image manipulation, so I expect it to run for a while.  However, it runs much more slowly than I anticipated and takes up no CPU according to the Windows task manager.  However, if I open up the vi menu, or if I grab a labview window and drag it around, the Application speeds way up (maybe 10x) and the CPU usage goes to >60%.

Why is it doing this?

How do I get it to run at full speed all the time?

Thanks,

Greg

[mfitzsimons]

It is as simple as reduce your delays or it just is not processsing the image.  If you create any while loop with no delay it will max out the CPU.  It maybe possiable that you are running out of memory so the Windows OS is disk swapping RAM  to disk so that is why it is running much slower than expected. 

[altenbach]

It makes no sense that code can speed up by a factor of 10 if the computer actually needs to do more work (dragging a window, etc.).

Something must be either terribly wrong with your code or there is posssible (unlikely) that you are exposing an unknown bug in LabVIEW.

What is the CPU usage if you don't drag windows around? Since you are saying the CPU usage goes up to >60%, I am assuming that the CPU usage is maybe <10% when it is supposed to do real work. I have no problems filling my CPUs to 100% for any real computations, while keeping the UI responsive at the same time. You need to find out why the processor is not kept busy if you are only watching it process images.

First of all, we need to know how you measure the speed of your code. Do you have actual code timing with and without your tweaking? Watching the CPU meter alone does not tell how much is spend on your computations.

If you cannot keep your processor busy working on your data, you need to inspect your code. Chances are that your code is not optimal and your code is spending most of the time making data copies in memory and switching threads or dealing with synchronous property nodes. How about race conditions? Do you have sufficient RAM or is swapping involved? Is there any hardware involved. Are the images to be processed available locally or do they come from a network server or imaging ssystem?

What kind of image manipulation are you doing? How big are the images? How many CPU cores do you have?

Message Edited by altenbach on 04-05-2008 11:59 AM

[tst]

Actually, I saw something not dissimilar a few days ago. I wrote some quick and dirty code to do something with the picture control, but it was very slow (it would take a second or two to run a loop instead of ~10 ms).

I decided to do a quick test by placing a couple of Tick Count nodes and measuring the difference to see which part of the code was taking up the time. Since the individual parts of the code were running fast inside for loops, I decided to stop the VI to see the exact section which was taking up the time, but each time I stopped the VI the indicators were showing numbers which were too small. After a minute of playing with this, I realized that whenever I pushed the abort button the VI would start running faster. If I kept it pushed, the VI would keep running faster (although I didn't check the CPU usage).

I didn't look into it, but I suspect some sort of thread swap issue or something else along those lines.

[GFDGreg]

Thanks everyone for their input.  This problem is not occuring this morning, although I changed nothing in the code.

It may occur again later, so I'm going add some more information.  Also, I'm interested in finding out the root cause so I can be on the lookout for this behavior it in more important software.

The program basically takes a subsection of an image and finds a histogram of it.  Then it moves over a pixel and takes a histogram of that. And so on, rastering through the image.  The image is monochrome, so I'm really looking for the number of white pixels at each subsection.  The IMAQ vis used are IMAQ set image size, IMAQ Draw, IMAQ Resample, and IMAQ Histogram.  I've done it some alternate ways with the same results though.

I have not gone in and meausured speeds with a millisecond timer.  I have it displaying the coordinates of the subsection it is currently looking at so I know where it is in the process.  Therefore I can get a quantitative feel for the raster speed and the difference is dramatic.  If the problem starts happening again, I will try to get some more quantitative measurements.

The CPU usage for LabView when I am not dragging windows around (and this problem is present) reads out at 0%.

The Task manager reads out about a GB of available memory (about 2GB total), so there should be plenty.

The code is sloppy as this is something I needed to put together quickly, but I'm pretty sure there are no race conditions.  There may be excess memory copies, but would that really cause the speed up when you move the window?

There is no external hardware.  Images are on local hard drive.

The image is a 960x800 8bit grayscale image.  (Though all the values are 0 or 255.).  I am not scanning the whole image though, just the center section which might be 600x500 or so.

Core Duo CPU.

[GFDGreg]

A bit more info:

When I wrote this morning, the program ran at >50% CPU.  When I run it now (again, not changing any code), it runs at >60% CPU.  Also, by my qualitative speed measurement, it seems to have picked up the pace a little bit as well.

Maybe it doesn't have anything to do with the code, and has to do with something else going on on the computer?