ListView with many SubItems is extremely slow

I am facing a issue that ListView becomes extremely laggy when I add many SubItems. For example, when I try to do a horizontal scroll, it takes about 1 second to update/repaint and that is not acceptable.

I want to be able to show small amount of rows (<50), but large amount of columns (>400). Only a few columns will be visible at the time. I also need to be able to set individual back colors to separate cells. Data within my list view will be populated once and not from the database.

I have tried enabling a double buffering and using a virtual mode, but it did not help much, if at all. I have found some 3rd party ListView alternatives, but they either did not work or had many unnecessary features and hence were very expensive to purchase.

Can you suggest how to fix this issue? Here is my sample code:

Code:

---

Private ListView1 As New ListView With {.Size = New Size(300, 400)}

Private Sub Form1_Load() Handles Me.Load
        Const columns = 500
        Controls.Add(ListView1)

        With ListView1
                .BeginUpdate()
                .View = View.Details
                .HeaderStyle = ColumnHeaderStyle.Nonclickable
               
                For c = 1 To columns
                        .Columns.Add(c.ToString, 50, HorizontalAlignment.Center)
                Next

                For r = 1 To 20
                        Dim l As New ListViewItem(r & "1")
                        For c = 2 To columns
                                l.SubItems.Add(r & c)
                        Next
                        .Items.Add(l)
                Next
                .EndUpdate()
                '.DoubleBuffered(True)
        End With
End Sub

---

To use differing colours set EnableVisualStyles.
I'm not sure about how to speed the scrolling up...

A DataGridView might be faster, worth a try.

400 columns is quite substantial, but a DGV probably would be faster, and they have a lot you can modify to get a similar look to a ListView

To be honest, I don't think having 400 columns in a ListView or DataGridView is a good idea. That just seems like to much to make the user search through. If possible I'd filter the columns to suit the user needs.

Quote:

---

but large amount of columns (>400). Only a few columns will be visible at the time.

---

This is your problem you thinking about this in the wrong way, if only a few columns will be visible at any time, then only load the data with those columns, when you need different data load it with a different set of columns.

Loading them all and hiding them or showing them based upon conditions is not a good idea and wont be much less code really then just having different methods loading the list view for the different views you want.

400 columns is ALOT of columns and is almost certainly causing your scrolling speed issues!

Quote:

---

Originally Posted by wes4dbt

To be honest, I don't think having 400 columns in a ListView or DataGridView is a good idea. That just seems like to much to make the user search through.

---

You do not know what I am trying to use it for. To put is simply, it will be used to visually recognize patterns in data sets. I see absolutely nothing wrong with having many columns in this case.

Quote:

---

Originally Posted by NeedSomeAnswers

400 columns is ALOT of columns and is almost certainly causing your scrolling speed issues!

---

In this day and age 400 columns is ridiculously small number given the processing power an average computer has. I would rather say that we can blame a poorly designed control, if no matter how configured, it cannot dynamically load data from large data sets. Even if I choose not to use a dynamic loading, there is still no reason why ListView should become laggy during the scrolling. All it has to do is to read the data of let say 100 cells and draw those cells. This whole routine is in no way a CPU intensive task.

I have just tried a 3rd party alternative control. It can literally load million data entries and shows no lag at all. I guess I will have to stick with it, given that ListView is not capable of accomplishing this task.

Quote:

---

Originally Posted by riov

You do not know what I am trying to use it for. To put is simply, it will be used to visually recognize patterns in data sets. I see absolutely nothing wrong with having many columns in this case.


In this day and age 400 columns is ridiculously small number given the processing power an average computer has. I would rather say that we can blame a poorly designed control, if no matter how configured, it cannot dynamically load data from large data sets. Even if I choose not to use a dynamic loading, there is still no reason why ListView should become laggy during the scrolling. All it has to do is to read the data of let say 100 cells and draw those cells. This whole routine is in no way a CPU intensive task.

I have just tried a 3rd party alternative control. It can literally load million data entries and shows no lag at all. I guess I will have to stick with it, given that ListView is not capable of accomplishing this task.

---

A ListView is a display control. If you're doing serious data crunching, I'd recommend either using a DataGridView, or doing all of your calculations with arrays in memory...

Hi,

I think you will have to implement some kind of 'Pageing' method -< show 15 columns then with Button or Key Right/Left
move forward or back to the next/previous 15 Columns

also the Listview has a AddRange method rather than just .Items.Add

The ListView is a GRAPHICAL display control... not a data display control. By your logic, I should be able to take a VW Bug to an F1 race, then simply claim that it's due to the poor design of the car that I didn't win the race. No...that's not it at all... the ListView has a purpose, and displaying gobs of data all at once isn't it... It can handle the data, just not all at once... you have to paginate it some how... either by virtual views and only load the data as it comes into view, or by adding buttons to navigate the pages.

If some other control can handle it, my guess is that it was built from scratch to handle data from the get go and isn't a graphical control, but a data control.

-tg