Access time for referencing a large table

[davidwnypf]

I have an application where a table is programmatically set to 1024 lines by 25 columns. In my application I access the tables' index value and edit position to control scrolling and line positioning. I also use 'floating' controls to set values in the table. I have found the execution time increases dramatically to get table properties from the table's control reference and property node when the table is this large. Is there a better way to get table properties from large tables that won't impact execution time? Thanks.

[LabVIEW_Joel]

If you are writing lots of values into the control, you might be able to save some screen redraws by using the Defer Panel Update property (look in the help under "Defer Panel Updates").

If you write, via a property node, to 100 indiv elements in your 2D array control (array, listbox, etc), you will get 100 redraws of the front panel. Instead, set the Defer Panal Updates property to True, set all 100 indiv values, and then set it property back to false (which forces the redraw). This method will save lots of redraws.

I think the property was added in LV 6.1

hope that helps!
joel

[davidwnypf]

I think I need to clarify my problem. Just accessing the index value and edit position of the table slows down with larger table sizes. I am not rewriting the table values, just repositioning my "floating" controls and scrolling the table. The positioning of the controls is based on the index value. Accessing this small cluster slows waaaay down for a table of this size. I have measured the performance degradation using the VI Profiler and it is significant...up to over a hundred milliseconds increase. Any insights? Thanks.

[Philip_Courtois]

Hi David,

I'm not sure that I know what you mean with "floating controls". Please explain what these are, and maybe attach an example showing the issue you are describing. Having multiple controls overlapping each other, means that LabVIEW has to update all the controls, even if there are only changes in one of the controls. Can this be the cause?

I created a small example to test the speed of accessing the property nodes "Index Values" and "Edit Position" (see the attached BigTable.vi). No matter how much I scrolled the table, I wasn't able to exceed an execution time of 0.15 milliseconds, so I don't see any dramatic delay anywhere close to 100 milliseconds.

Let me know if you're doing something else than I am, thanks.

[davidwnypf]

Hi Philip,

Thank you for your response. I tried your example and found the same problem that I am experiencing. When the index value is at the top of the table, Row = 0, Col = 0 I measured an iteration time of 140 msec. When I scrolled down the table to an index position of Row = 1000, Col = 0 the iteration time increased to over 2000 msec. This is the exact problem I am talking about. The Labview code causes longer access times when reading the table index at the bottom of large tables. This is only true for the index position. The edit position is consistently fast no matter where you click on the table. Any comments? Thanks.

[Philip_Courtois]

Hi David,

This is VERY odd. What is the "Execution time per iteration" if you don't move the mouse? Mine is about "0.0083" milliseconds when I leave the mouse alone, and "0.1500" milliseconds as the absolute max value if I move the scroll bars VERY fast back and forth.

Are you running any processor starving applications next to LabVIEW (please check the Task Manager)? Are you runnning my code WITHOUT ANY MODIFICATIONS? What's your PC specs? Have you tried this on another PC with the same results?

[davidwnypf]

Hi Philip,

A few points:

1. Your iteration time is actually in tens of seconds. You are dividing the time (in milliseconds) by 10000.

2. If I set the index position to 0,0 I get an iteration time of about 15 msec.

3. If I set the index position to 1000,0 I get an iteration time of about 1.5 seconds.

I set the index position with the vertical scrollbar then leave the mouse alone. My issue is that there is a bug in Labview where the time needed to calculate the index position is dependent on the size of the table. If an application uses a large table the application starts to inexplicably bog down. I have also seen that setting colors in large tables can take a long time if the index position is at the end of the table. Thanks.

[Philip_Courtois]

Hi David,

In my example I am using a For Loop to run the code of interest (Property Node) multiple times, so I can calculate the average execution time PER ITERATION of the loop. That is why I'm dividing the total time with the number of iterations (in this case 10,000) to reflect how long it takes to access ONE Property Node call. You can verify this by changing the constant to 1,000 or 100 and still get approximately the same results. I choose 10,000 to get a better resolution of the averaged time.

The results you are mentioning should be divided with 10,000. They will then reflect similar values to what I'm seeing (0.0083 msec for position "0;0" and 0.15 msec for position "1000;0"). Notice that if you replace the Property Node and the two indicators with a Random Number function connected to a Numeric indicator, you will see execution times in the range of 0.0004 msec per iteration. The Property Node call is therefore in the factor of 20x slower (expected behavior), but not anywhere close to the numbers you are reporting.

Let me know if you are still seeing slow performance even when looking at the execution time per iteration.

[jfazekas]

I also am seeing the same problem with the Table control.  I've attached a sample VI that shows the update time for 100 cells is on the order of 2.5 seconds.  Notice also that deferring panel updates does not help any.

[Dennis_Knutson]

But you are setting defer panel updates to true and then false and this is all after you run the for loop. Your case statement is run after because of data flow. Remove the setting of panel updates to false and wire from the error OUT of the property node to the for loop to ensure that the for loop runs second.