Testing speed of a computer?

[JPrevost]

I thought this might be of some help or maybe just an idea. Instead of reading in a computers properties (which sometimes mean nothing), instead perform a small test or tests to measure the speed of a system. Attached is a picture of code that measures how fast a while loop will run doing a simple compare and display. You can modify it (obviously) so as not to display the iterations. I think this could be useful in my application for determining how often I refresh the GUI with new data. By performing a small speed test that is really fast on any machine, I can then, depending on the results, run an even longer test to get more accurate without killing the load time. These tests will eventually write to a cfg file with their results and the main program will use these results to determine the GUI refresh rate . Anybody use this or know of an easier way of measuring a computers speed?

Running my little test program I registered the same at below and normal priority, around 5.4MHz. Above normal priority registered the lowest with 2.2MHz, and high and critical got 5.8MHz. The only explination for the "above normal priority" doing the loop the slowest was that it stopped half-way to refresh the iterations display where as the high and critical didn't even bother until the loop was finished. The below and normal updated the iterations display while running and showed a very small hit in performance. Just thought I'd share.

I know there is the VI Profile under Tools_advanced, but how would one go about getting the results for later use in the VI? The VI Profile showed 1.7826s to run and my results were 1.78299s . Close enough don't you think.

[Yair]

True benching of a computer can not be done over the space of a few seconds since you have no way of knowing what else the computer is doing at the moment. If I remember correctly, most benching programs (and there are quite a few around) take at least 30 seconds to perform each individual test (I think the common ones test things like 3D display, File I/O, real processor speed and so on).

Also, simply running a loop is not a very good measure of how a computer would handle LV applications. It will give you a single number, but you might find out that some computers will be much slower or faster in doing certain types of operations and this will not be reflected in your test. Generally, benching involves running several types of tests to check for different kinds of requirements.

Additionally, using a for loop would allow LV to better optimize the execution and refreshing the display inside the loop is what would actually cause most of the overhead, unless you defer the panel updates. You should also consider that different LV versions also affect this, so to get a single meaningful number you will need to compensate for all kinds of factors.

[JPrevost]

I understand completely but I I'd like to integrate a fast series of tests that can be performed on the first run of my program so it can get a "good" feel of the users current running state. There will be a warning message before this test opens that will ask the user to close all unnecessary applications and to run the test just like they would run the main program. From this simple fast test that takes less than 5 seconds on almost every machine, you can get a feeling for how fast you can update the screen. My other option was to have a feedback that monitored the queue state. If the queue got too big it would slow down the refresh rate. Do you think this is a better method?

[Michael Aivaliotis]

My other option was to have a feedback that monitored the queue state. If the queue got too big it would slow down the refresh rate. Do you think this is a better method?

Ah, so now we get down to fixing your real problem. You have queue backlogs? How can we fix this? Have you tried "deferpanelupdates"?

[JPrevost]

Ah, so now we get down to fixing your real problem. You have queue backlogs? How can we fix this? Have you tried "deferpanelupdates"?

Never heard of this, "deferpanelupdates"

[Yair]

Never heard of this, "deferpanelupdates"

Sure you have, just look at the last paragraph of my first post.

It's a front panel property which tells LV not to update it unless absolutely necessary. You can get it to it by wiring the VI's Panel reference into a property node.

Remember that there is no point in updating the display too much. More than 10 times a second is usually something that's too fast for most people. If you tell us what you're actually doing, that might help.

[Neville D]

I understand completely but I I'd like to integrate a fast series of tests that can be performed on the first run of my program so it can get a "good" feel of the users current running state. There will be a warning message before this test opens that will ask the user to close all unnecessary applications and to run the test just like they would run the main program. From this simple fast test that takes less than 5 seconds on almost every machine, you can get a feeling for how fast you can update the screen. My other option was to have a feedback that monitored the queue state. If the queue got too big it would slow down the refresh rate. Do you think this is a better method?

I would not try to update a GUI more than 5 times a second. Any faster would be overkill. Usually every 0.5 s is good enough. You could use the "defer panel updates" property to limit the number of updates, and then you wouldn't need to worry about the speed of your processor.

Make sure:

1 all loops in your code have a Wait ms with an appropriate time (even 0ms is better than nothing)

2 limit transparent graphical objects on your panel

3 do not overlap objects.

Note also that raw processor speed is anyway not a measure of system performance with LabVIEW.. if doing a lot of array manipulations, poor labview code will require more and more contiguous memory, and calls to the LV memory manager drastically affect performance.

Read the Labview performance and Optimization App note for further info.

Neville.

[JPrevost]

I would not try to update a GUI more than 5 times a second. Any faster would be overkill. Usually every 0.5 s is good enough. You could use the "defer panel updates" property to limit the number of updates, and then you wouldn't need to worry about the speed of your processor.

Make sure:

1 all loops in your code have a Wait ms with an appropriate time (even 0ms is better than nothing)

2 limit transparent graphical objects on your panel

3 do not overlap objects.

Note also that raw processor speed is anyway not a measure of system performance with LabVIEW.. if doing a lot of array manipulations, poor labview code will require more and more contiguous memory, and calls to the LV memory manager drastically affect performance.

Read the Labview performance and Optimization App note for further info.

Neville.

Not updating more than 5 times a second isn't an option. It needs to be 17Hz on most systems, no if ands or buts about it. The reasoning is too complicated to get into here. I'm going to try the defer panel updates property and see how that works out.

1. All my loops have a wait of either 0 or 1ms. The 0ms is for user events that I don't want to miss on even the slowest machine.

2. Working on this one. Removing the transparent objects has been tuff. I'm forcing myself to revamp the whole setup to have more uniformity.

3. When you say overlap, do you mean their rectangles made by their extreme edge or can they overlap so long as the moving parts don't overlap?

I did some more thinking (yes, I do this from time to time) and I thought of a better way to do what I want. It'll just measure how long it takes to exicute the loop that updates the GUI. The queue also works well as a measure.

Is it just me or do LabView's instruments take more power than even most ActiveX components? Are the newer instruments more code efficient than the classical? I didn't think they would be but apparently the newer charts/graphs are better than the classical on my machine. Maybe NI is getting better with how they write these instruments? One can only hope they aren't relying on faster machines to operate simple legacy software/hardware... I hate code bloat!

[Yair]

3. When you say overlap, do you mean their rectangles made by their extreme edge or can they overlap so long as the moving parts don't overlap?

I believe that the overlapping should be avoided for the entire rectangle.

Is it just me or do LabView's instruments take more power than even most ActiveX components?

As far as I know, LV does all of its graphics on its own (to support multiple platforms) using MESA and so it is not as efficient and fast as controls displayed in other compilers which presumably use the OS and hardware support for display.

[Michael Aivaliotis]

Not updating more than 5 times a second isn't an option. It needs to be 17Hz on most systems, no if ands or buts about it. The reasoning is too complicated to get into here. I'm going to try the defer panel updates property and see how that works out.

1. All my loops have a wait of either 0 or 1ms. The 0ms is for user events that I don't want to miss on even the slowest machine.

You probably need fast updating because you are using the GUI as feedback for some manual tuning operation that the operator performs?

Are you using an event structure? If so, then I don't see how you can miss user events. They are qeued up in the event structure. I'm not sure why you are having such problems with slow screen updates. Is it possible to see an image of your code?

[PJM_labview]

Not updating more than 5 times a second isn't an option. It needs to be 17Hz on most systems, no if ands or buts about it. The reasoning is too complicated to get into here. I'm going to try the defer panel updates property and see how that works out.

Just a quick comment about that statement. I think what other people mean if that you might want to consider updating the display at a slower rate while still logging your data (if applicable) at an higher rate. It may not apply in your situation, but this is just a thing to keep in mind.

As far as I know, LV does all of its graphics on its own (to support multiple platforms) using MESA and so it is not as efficient and fast as controls displayed in other compilers which presumably use the OS and hardware support for display.

I dont think the mesa library that ship with labview support hardware acceleration (unfortunately). This mesa.dll (version 3.0.0.0 Copyright

[JPrevost]

You probably need fast updating because you are using the GUI as feedback for some manual tuning operation that the operator performs?

Are you using an event structure? If so, then I don't see how you can miss user events. They are qeued up in the event structure. I'm not sure why you are having such problems with slow screen updates. Is it possible to see an image of your code?

Yes, this is a feedback requiring manual tuning operations. Skip a few key components like a quickly set error code from the ecm and you'll curse having missed it. That was the whole reason for developing this custom hardware and software... so that we don't miss a thing. The stock interface on these older ecm's was 160baud. 18 bytes of semi-useful data, a few useless bytes = 0.9Hz update rate . Slow? Yeah. So a friend of mine designed the heardware and some DOS software to get all the good stuff at a much faster rate. Since I'm working in the windoze xp world it's become obvious that serial ports aren't used much for daq anymore.

I didn't know the events were queued. That means I can run that loop at like 10ms. Thanks. Learn something new every day. I thought that in the past, the events might be missed. Not sure why I thought that. Totally unfounded. My code isn't ready to be public but I'll give out as much as I can soon. Tomorrow is my day off, hopefully then I'll be able to post some code.

Just a quick comment about that statement. I think what other people mean if that you might want to consider updating the display at a slower rate while still logging your data (if applicable) at an higher rate. It may not apply in your situation, but this is just a thing to keep in mind.

I dont think the mesa library that ship with labview support hardware acceleration (unfortunately). This mesa.dll (version 3.0.0.0 Copyright

[PJM_labview]

Do you think I might be better off with ActiveX components considering my software will only be run on PC's, no Mac's? I heard somewhere that LabView wasn't too good with ActiveX... please tell me this is also unfounded.

Well, I would use activex only as the last recourse. If I have a way of doing something in labview (even if not perfectely), I will not use ActiveX. There are too many issues of stability and compatibility (for example your client install a piece of software [unrelated to your software] on his PC that update one of the ActiveX component you were using and suddenly your whole application is no longer working).

Just my though on the topic...

PJM