LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Poor cursor performance in LabVIEW 8.2.1

Cursor performance in LabView 8.2.1 is dramatically worse than LabView 7.1.
 
The attached LabView 7.1 VI populates a graph with {1, 10, 100, 1000, 10000, 100000} cursors by generating an array of cursor clusters and setting the CursorList property.
 
Execution time for plotting 111,111 cursors using the CursorList property is as follows:
 
LV 7.1 :   23 seconds
LV 8.2.1 "OldCurs": 1825 seconds
LV 8.2.1 "NewCurs": 1875 seconds
 
That's not a typo: for 100,000 cursors, LV 8.2.1 is 100 times slower than LabView 7.1.
 
(The cursor definition changed in LabView 8, so when you try this on LabView 8, you will probably want to try running with both the backwards-compatibilty "OldCursList" property and the new LV 8 native CursList. That's what "OldCurs" and "NewCurs" refer to above. Performance is equally awful.)
 
LabView 8.2.1 seems to have O(n^2) running time (vs O(n) in LabView 7.1), so the speed differential gets larger and larger as more cursors are added to the graph. This can be seen in the attached log-log plots. Note that the LabView 7.1 graph is reasonably linear and goes to 10^6 cursors while the LabView 8 graphs go to only 10^5 cursors; this was because LabView 8 had not finished running after 3 hours. I gave up.
 
I have previously filed a related bug on this issue (#831169, "can't open graph containing 25,000 cursors in LV 8") which was "resolved" in the LabView 8.2.1 release notes. ("3YT8QDTC: Fixed an issue where LabVIEW hangs or crashes when you open a VI that contains a graph with thousands of cursors".) This bug was fixed but the underlying performance issue was not addressed. There is simply no reason why objects cannot be drawn on a graph in linear time, and LabView 8.2.1's performance is very much worse than that.
 
The poor performance of LabView 8 cursors is causing significant performance problems for my application. I use thousands of cursors in my application because I am placing text labels on thousands of points pulled from a database. (This cursors are not draggable; this should not require any fancy event handling.) I will have to artificially limit the number of displayed cursors to 5,000 or less in order to avoid apparent hangs in the application.
 
Another minor issue: in LabView 8, the CursorList is a typdef array of a non-typedef'd cluster. This is poor style. One of the first things we hammer into any new LabView developer is that you should typedefs your clusters and build non-typedef arrays from those typedef clusters. The Cursor cluster has needed to be a typedef for a long time, but the LabView 8.2.1 implementation is backwards and results in coercion dot when writing to the property node without giving any of the advantages of a typdef'd cluster.
 
Sincerely yours,
 
Rob Calhoun
Download All
Message 1 of 6
(3,751 Views)

I have a hard time imagining a situation where somebody would need more than a handful of cursors.

At one point it would seem more reasonable to use "plot images" overlays or similar. Of you have 100000 cursors on a 500x500pixel graph, it would be difficult to specifically grab one of them. Also the cursor palette will be a mile long.

We can see that for very few cursors 8.x it is actually faster than 7.x 🙂

Message 2 of 6
(3,736 Views)
LabView has no way of drawing text labels on plots other than cursors, so cursors are what we use when we want to label points. The "cursor style" is 0 (invisible) and the point style we often make invisible as well; all we are using is the text. As I said, the cursors are not draggable, so selection is not an issue.  
 
If you have10,000 points on the graph and you want to be able to label them so that the user can see labelled points when they zoom in using LabView's zoom tools, then you need to draw 10,000 cursors on the graph. Perhaps the attached plots make it clearer: "zoomout.png" show the graph with thousands of points and thousands of cursors. It covers a two hour period and is completely illegible, although even at this scale I can tell what time ranges are "interesting" because I know what I'm looking for. When you zoom in to a 5 second segment with LabView's graph tools ("zoomin.png"), you can see everything nicely labelled. If you put labels on everything at the outset, all of the points still have labels when you use the scroll bar, rescale the graph etc.; it's LabView's problem to redraw the screen instead of my problem, and that's the way it should be.
 
There are various workarounds I can think of (monitor user zooming of the graph in an event loop and dynamically regenerate the cursor list as appropriate for the current view) but that's a lot more work than just dumping them all on the graph and letting LabView take care of handling the zoom.
 
>We can see that for very few cursors 8.x it is actually faster than 7.x
 
Only when "very few" = 1! 
 
-Rob
Download All
Message 3 of 6
(3,726 Views)
Sorry for hijacking the thread, because I really don't have a solution for the cursor problem. However, I probably would throw a bit more code on it and only show the cursors above a certain zoom level and then only for the few cursors visible on the screen.
 
You can draw text using the plot images property (example: Graph Plot Area Images.vi). Since all picture commands are allowed, drawing text will work too. I don't know about performance. There is also the annotate feature. Have a look at the example "Programmatically Annotate a Graph.vi" in the example finder.
Message 4 of 6
(3,711 Views)
> There is also the annotate feature. Have a look at the example "Programmatically Annotate a Graph.vi" in the example finder.
 
Facinating. I've only switched from LabView 7.1 to LabView 8 in the last few weeks and did not know about the AnnotationList property. The data structure is nearly identical to graph cursors, but the performance of AnnotationList is vastly better; see attached graph. (This one goes up to 10^6 points, like the LV 7.1 graph above.) Note in this case the log-log plot is linear with a slope a bit less than 1, so it's a bit better than O(n). Great!
 
Using the same VI as above but chaning to the AnnotationList property yields the following results for 111,111 "annotations":
 
LV 8.2.1 "AnnotationList": 14.8 sec
 
This fabulous! Using AnnotationList the performance is actually a 33% improvement over cursors in LabView 7.1. (Annotations appear to be cursors without the "cursor" part that I rarely use anyway, so they are a complete replacement for cursors in my application.)
 
Thank you very much for an excellent suggestion!
 
-Rob Calhoun
 
(NI: I still think you should fix the cursors!)
 
 
Message 5 of 6
(3,690 Views)
'glad it worked out. 🙂

@Rob Calhoun wrote:
(NI: I still think you should fix the cursors!)


I agree with that. Drawing cursors should be O(n).
 
The current behaviour is even worse than O(n^2), because that would still give a straight line on a log-log plot. It is difficult to understand what could give rise to such a complexity, but it should probably give the developers a hint at what to look for. 😉
Message 6 of 6
(3,678 Views)