Chart and Graph Performance Report

[PeterB]

Hi folks,

a colleague of mine at work (Vito) has recently risen to the challenge of becoming a wire worker. He is applying his new found skills to a medium sized LV project. During his exposure to charts and graphs in LabVIEW, he decided that he liked some features of the XY graph, but quickly became aware of the performance hit for a large number of points (1000) and/or a fast update rate (50Hz).

Being unable to find any definitive figures showing the (relatively slower) performance of graphs compared to charts, he decided to perform the testing himself. To this end, I am uploading the details of his testing and results. A screen shot of the MS word document is attached (showing one of the BDs used), along with the example vis used. Timing details were measured using the VI profiler built into LabVIEW.

regards

Peter

Download File:post-1272-1139468483.vi

Download File:post-1272-1139468497.vi

Download File:post-1272-1139468510.vi

[Yuri]

1. Sorry, this test incorrect. For example look: the test for graphic method=GRAPH "more slowly" than " XY GRAPH ". But GRAPH-method use N-poits, XY-GRAPH-method use 2*N-points. hmm, it is a surprise...

Say to your colleague (Vito:): please, remove from the diagram "cancel button " and "wait"-function

2. Profile? There is no hope - he is mistaken as the PC-timer.

Please, also read LabVIEW Help-> Profile Performance and Memory Window:

" Display-... Display can be inaccurate if you do not right-click the control or indicator and select Advanced

[Gary Rubin]

4. Your topic is very interesting. I modified examples - everyone can try. Please correct them to improve. (Now for LV8 ...)

5. My results are located in examples for my PC (AMD Athlon XP 1900+ 1.6GHz, 1.5 GB RAM).

For example, for me unexpectedness: (Almost always) use reference for data writing - very slow

Yuri,

Unfortunately, I can't run your code (I'm on LV7.1), but I am quite surprised by your tables. Do I understand correctly that your results are consistently better when you pass data via a local than when you wire directly into a terminal?

I am quite surprised by this, especially considering the following from the LabVIEW

[Yuri]

Yuri,

Unfortunately, I can't run your code (I'm on LV7.1), but I am quite surprised by your tables. Do I understand correctly that your results are consistently better when you pass data via a local than when you wire directly into a terminal?

I am quite surprised by this, especially considering the following from the LabVIEW

[Gary Rubin]

Yuri,

Thank you for providing the LV7.1 version of your test. I've duplicated your test in my own VI that I used for benchmarking (attached) and get similar results (local is about a factor of 2 faster than terminal). I'm still very surprised by this. You are correct that the citation I made from the NI app note referred to memory efficiency, not execution time, but my previous experience has always been that the two are very closely related.

One thing I did notice is that when I show buffer allocations in my vi, it shows me that there is an array allocation associated with the terminal, but not with the local variable. This seems inconsistent with NI's recommendations, which says that local variables create copies of the data. Are there any NI lurkers out there who can comment on this?

Gary

Download File:post-4344-1147350446.vi

[Grampa_of_Oliva_n_Eden]

Yuri,

Thank you for providing the LV7.1 version of your test. I've duplicated your test in my own VI that I used for benchmarking (attached) and get similar results (local is about a factor of 2 faster than terminal). I'm still very surprised by this. You are correct that the citation I made from the NI app note referred to memory efficiency, not execution time, but my previous experience has always been that the two are very closely related.

One thing I did notice is that when I show buffer allocations in my vi, it shows me that there is an array allocation associated with the terminal, but not with the local variable. This seems inconsistent with NI's recommendations, which says that local variables create copies of the data. Are there any NI lurkers out there who can comment on this?

Gary

Please see attached mod of the previous.

I used "defer Panel updates" to be able to measure the updates w/o screen update times.

Repeated runs show that the terminal will SOMETIMES (do a bunch of ctrl-r) run as fast as the local.

The "nightmare" is now faster because I moved the reference node outside the loop.

Nice topic!

To quote one of my old girl friends daughter "I want to go fast Mommy!"

Ben

Download File:post-29-1147353606.vi

[Yuri]

Please see attached mod of the previous.

I used "defer Panel updates" to be able to measure the updates w/o screen update times.

Repeated runs show that the terminal will SOMETIMES (do a bunch of ctrl-r) run as fast as the local.

The "nightmare" is now faster because I moved the reference node outside the loop.

Nice topic!

To quote one of my old girl friends daughter "I want to go fast Mommy!"

Ben

Download File:post-29-1147353606.vi

Ben, thanks for "defer"-property. I did not know (!) it. It is bad

But the common conclusion remains - use of reference slows down (noticeably) speed of execution ((

If to think: It was always (and in old versions, for example LV5.1): use of property (== linked reference) for change of graphics-attributes is Nightmare #2!

For me it: "perestroika" of ideologies of my programs

Probably, it is time to write new recommendations for LabView-programmers and to make tests for "get/set" for different types of data (for example array of clusters), and for converts of data- types (variant and more).

NOTE: you write: "The" nightmare " is now faster because I moved the reference node outside the loop "

Excuse, but the position of reference can be any. Inside of cycle any way the copy of reference is created (automatically). Check up, please, timing does is not change.