Multicolumn listbox - fastest way to update items and headers?

[Ola_A]

I have a small multicolumn list box that is very slow to update. I thought it was the database queries that took most of the time, but I see now that the acutal MulticolumnListbox.ItemNames and MulticolumnListbox.ColHdrs[] take measurable time. About 0.12s to add+show 10rows with 30 columns, with column headers.

I saw that my code did the write to MulticolumnListbox.ItemNames for each cell that  I produced, and then you could actually see the list box being filled up.

Now changed it so that I write to ItemNames once every row, and that improved things slightly, but not as much as I had hoped. Time went down form maybe 0.12s to 0.10s.

I remember reading about this some time ago, then about coloring of the cells. But I don't find it back.

So is it slow to add some columns to a MulticolumnListbox? Or in another way, what is the best way to add 10 columns to a Multcolumn listbox with 20 columns and 10 rows?

Ola

[Hooovahh]

What version of LabVIEW are you in?  And can you post any code?  Here is a Virtual MCLB made over on LAVA that demonstrates how to only show so many rows at a time, and then update the rows as a scrollbar is moved.  I believe it was around LabVIEW 2016 that there were improvements made to the MCLB and Tree to help with performance of large data sets.  Still 100ms doesn't sound like that much time, is it an operation that happens often?  Is it noticeable?  Have you looked into defer front panel updates?

https://forums.ni.com/t5/Example-Programs/How-to-Disable-Enable-Front-Panel-Updates/ta-p/3530344

[pincpanter]

You can use the DeferPanelUpdates property of the Panel object in VI class. Set it to true before changing ItemNames and headers. Set to false afterwards.

This will prevent updating the control until all data have been changed and usually allows a quicker redraw.

[Ola_A]

Hoovah and pincpanter, I tried Defer panel update, but it does not work. Meaning that I still see the updates during the time I have defer_panel_unpdates=true. Can you see the fault in my code? I put the functionality in a sub vi, as attached. Before my loop that extracts data from db and updates the multicolumn listbox, row by row, I added the following. With a similar call with false afterwards.F

For this issue I don't think Defer panel updates is the solution, see next post, but I like to be able to use it in other situations. I have a program that works poorly on slow pc's due to many control updates for example, and here the defer panel updates could really help.

Ola

[Ola_A]

Hooovahh, I am in Labview2015 currently. The delay I measured was this 0.1-0.15s per row inserted, so already after 10-20 rows the total delay is noticeable, but not terrible in itself. But it adds to the delay of my sql searches, and these are 200-700ms, per row.

But I must back of a little from my question, it seems now that the timing profiles I made where I found the 0.1-0-15s delays where done with a lot of subVi's front panels open, so a lot of delays are added from theses front panel updates. When I redo the tests with all subVis closed the delay from the additino of rows in multicolumn listbox is very low. (But noticeable if I add the data cell by cell).

I also understand now that the data I get from the Profile/Performance&memory does not count the waiting time in my sql queries(!) And since these are the main delays I started to look into wrong part of the code.

So far I've seen that opening a db connection takes consideralble time, so I will aim to leave the connection open for longer parts and see if this helps. I also see very interesting things when measuring the time for things like

• Open connection.
• Doing sql search 1st time.
• Doing sql search 2nd time.
• Closing db connection.

For remote production db opening takes most time, 1st search is slowest, 2nd much faster, close takes 0ms.

For local db opening is fast, 1 search is quite fast, second search is much slover, close takes 20ms.

Of course it is not the same db servers, maybe differences in query cache or whatever.

Ola

[Yamaeda]

---

@Ola_A wrote:

I have a small multicolumn list box that is very slow to update. I thought it was the database queries that took most of the time, but I see now that the acutal MulticolumnListbox.ItemNames and MulticolumnListbox.ColHdrs[] take measurable time. About 0.12s to add+show 10rows with 30 columns, with column headers.

I saw that my code did the write to MulticolumnListbox.ItemNames for each cell that  I produced, and then you could actually see the list box being filled up.

Now changed it so that I write to ItemNames once every row, and that improved things slightly, but not as much as I had hoped. Time went down form maybe 0.12s to 0.10s.

I remember reading about this some time ago, then about coloring of the cells. But I don't find it back.

So is it slow to add some columns to a MulticolumnListbox? Or in another way, what is the best way to add 10 columns to a Multcolumn listbox with 20 columns and 10 rows?

Ola 

---

A quick test shows that the multicolumn listbox properties are very slow. Prepare all data/array externally and write all at once.

/Y

[Hooovahh]

The performance improvement I was thinking of is from LabVIEW 2013's release.  Here is Christina Rogers talking a bit about what improved and how.

As for the defer front panels I think you are doing it right. Here is a post on the idea exchange which shows the most basic calls which looks like what you are doing.  If you do try using this method, be sure and clear the errors before going into the undefer.  If an error happens between defer, and undefer, it won't ever undefer and your UI will look like it is locked up.