none
adding items to listview is very slow RRS feed

  • Question

  • I have 300 items to add to the listview suing CF 1.0.

    ListViewItem lstItem = new ListViewItem(finalList[ i ].qNum.Trim());

    lstItem.SubItems.Add(finalList[ i ].qDesc.Trim());

    lstItem.SubItems.Add(finalList[ i ].qDesc2.Trim());

    lstItem.SubItems.Add(finalList[ i ].qDesc3.Trim());

    if ((_check || finalList[ i ].alreadyChecked) && listView1.CheckBoxes)

           lstItem.Checked = true;

              listView1.Items.Add(lstItem);

     

    I clear the listview and then we see the scroll bar getting smaller as the listview is filling up. Anyway to make it faster?

    Thanks

     

    Friday, July 14, 2006 2:20 AM

Answers

  •  

    Aaargh.  I hate it when that happens...

    However, you can achieve the same effect by replacing AddRange with

    foreach(ListViewItem lv in lvItems)
    {
        listView1.Add(lv);
    }

    The main idea was to do the prep work outside the control update as Erik has suggested.

    Dan

    Wednesday, July 19, 2006 5:10 PM

All replies

  • Yes, surround your "Add" loop with a BeginUpdate() and EndUpdate() call.  This is part of the ListView class, and support by the Compact Framework.

    Erik

    Friday, July 14, 2006 2:28 AM
  • I tried adding

    listView1.BeginUpdate();

    before my loop but its still taking a long time when it gets to the

    listView1.Items.Add(lstItem);

    That's what I notice when I run it in degug mode.

    I'll look at it some more. Thanks for the try.

     

    Friday, July 14, 2006 3:02 AM
  •  

    You might try creating your listview items and adding them all at once using ListView.Items.AddRange().  I believe this will cut down on the number of messages sent to the ListView, thus speeding up the process.

    For instance,

    ListViewItem[ ] lvItems = new ListViewItem[finalList.Length];

    for (int index = 0; index < finalList.Length; index++)
    {
        ListViewItem lstItem = new ListViewItem(finalList[index].qNum.Trim());
        lstItem.SubItems.Add(finalList[index].qDesc.Trim());
        lstItem.SubItems.Add(finalList[index].qDesc2.Trim());
        lstItem.SubItems.Add(finalList[index].qDesc3.Trim());

        if ((_check || finalList[ index].alreadyChecked) && listView1.CheckBoxes)
            lstItem.Checked = true;

        lvItems[index] = lstItem; 
    }

    listView1.BeginUpdate();
    listView1.Items.AddRange(lvItems);
    listView1.EndUpdate();

     HTH,
    Dan

    Friday, July 14, 2006 4:48 PM
  • AddRange method is not valid for the compact framework. nice try
    Tuesday, July 18, 2006 3:35 AM
  • Marco,

      Your original question was how to keep the view from updating and scrollbar from growing smaller and smaller on your screen.  The BeginUpdate / EndUpdate should do this.  Can you confirm?

      Your remaining problem appears to be that adding lots of list items, and doing subitems and calculations besides, takes a while.  This is true.

      I don't know what you're doing exactly, but can you do prep work ahead of time?  For example, could you create your 300 list items in an array, or pre-Trim() all of your subitems, before you get to the loop.  For example, create the array of 300 items, and then clear the list and add them all.  Might take the same amount of time, but the user doesn't have to stare at a blank screen.

    Hope this helps,

    Erik

     

     

    Tuesday, July 18, 2006 2:31 PM
  •  

    Aaargh.  I hate it when that happens...

    However, you can achieve the same effect by replacing AddRange with

    foreach(ListViewItem lv in lvItems)
    {
        listView1.Add(lv);
    }

    The main idea was to do the prep work outside the control update as Erik has suggested.

    Dan

    Wednesday, July 19, 2006 5:10 PM
  • sorry fot the delay but just came back from vacation...

    the delay still takes a few minutes to load and that's only for 330 items.

    there is a one second delay each time the code goes through this loop

    foreach(ListViewItem lv in lvItems)

    {

    listView1.Items.Add(lv);

    }

     

    i'll keep looking. Thanks to all for the help

    Tuesday, August 1, 2006 12:58 PM
  • Hi,

    just knocked up a quick sample in VB.Net, with an option to do beginupdate/endupdate as a checkbox. Can only run it on an emulator, as I have no PPC with me to test on.

    To load 300 items without beginupdate/endupdate takes 6.2 seconds approx
    To load 300 items WITH beginupdate/endupdate takes 2 seconds approx

    The code is...

       Dim ix As ListViewItem
            Dim ict As Integer
            ListView1.Items.Clear()
            Dim st As Double = Environment.TickCount
            If CheckBox1.Checked = True Then
                ListView1.BeginUpdate()
            End If
            For ict = 0 To 300
                ix = New ListViewItem
                ix.Text = ict
                ix.SubItems.Add("SI1 " & ict)
                ix.SubItems.Add("SI2 " & ict)
                ListView1.Items.Add(ix)
                ix = Nothing
            Next
            If CheckBox1.Checked = True Then
                ListView1.EndUpdate()
            End If
            MessageBox.Show(Environment.TickCount - st)

    I remember doing quite a few tests in eVB on loading listboxes/listviews/grids(http://www.devbuzz.com/content/zinc_evb_performance_grid_pg1.asp), and found that the listview was generally quicker to load if you treated it with love and care

    HTH

    Pete

     

    Wednesday, August 2, 2006 4:04 PM
  • good solution it do improve the performance by half although is still slow

    Wednesday, February 14, 2007 4:15 PM
  •  

    I was facing the same problem

    Only the AddRange method solved it ....

     

    • Proposed as answer by suttleTubtle Wednesday, November 25, 2009 3:27 PM
    Monday, November 26, 2007 8:20 AM
  • I am unsure if this applies to the original case, but I discovered when I added a custom ListViewItemSorter before populating my ListView, it slowed down the loading time considerably.

    By setting the ListViewItemSorter to null before populating the ListView and then reassigning my Comparer : IComparer afterwards, the loading time was only a fraction compared to before.

    Ex:
    // Before populating the listview, make sure the sorter is nullified
    listView1.ListViewItemSorter = null;
    
    //... create listview items and add them to the listview
    
    // ReAssign the sorter to the listview
    listView1.ListViewItemSorter = new lviSorter();
    
    
    // and then somewhere else this would be declared
    public class lviSorter : IComparer
    {
        ...
    }



    - Matt
    • Proposed as answer by steenz Sunday, September 19, 2010 10:12 AM
    Wednesday, November 25, 2009 4:04 PM
  • I know its old thread. And i know my issue is not the same. (i was trying to figure out how to add an array to listview.) and you guys answeard it. So thanks. :)
    Sunday, December 27, 2009 2:11 PM
  • I know this thread is old, but suttleTubtle's suggestion solved my problem, which was slightly different, and I wanted to post this somewhere to help other people with similar problems.

    In my case, I was adding a reasonably large set of items to the ListView one by one using the Add method, but also invoking Begin- and EndUpdate(). This used to work fine, until I updated the ImageList associated with the ListView to contain more images of a better resolution and higher color depth. In Debug mode everything still worked fine, but for some reason the performance in Release mode was absolutely dreadful.

    Playing around for a long time with Stopwatches to determine the problem, I discovered that really -adding- the ListViewItems I created to the ListView was causing the performance issues. However, one can hardly do without, and I couldn't figure out why this could be different between Release & Debug modes and with a small or a (only somewhat) larger ImageList.

    As it turns out suttleTubtle was spot on, and the custom ListViewItemSorter that I was using for the ListView was causing the problem. I now suspect that items are sorted in the background whenever you add one, even with BeginUpdate() invoked. For some reason, the associated images and Release vs. Debug mode make a difference, but temporarily removing the ListViewItemSorter solves the problem completely.

    Thanks!

    Sunday, September 19, 2010 10:18 AM
  • Thank you suttleTubtle!!! I've been trying to figure this out for days without any luck. By initializing the itemSorter AFTER populating the listview, the time it took to populate my list went from 35 seconds to 1 second! Woohoo!
    Wednesday, November 17, 2010 5:27 PM
  • Hi,

     

    I am facing the same problem. The following code takes around 40 secs for 100 images, and my client does not accept this.

     

      For x = 1 To NumberImages

                    ImagepathA = "C:\ImagenesInput\TAX.TIF"

                    img = New System.Drawing.Bitmap(ImagepathA)

                    imagelist1.Images.Add(img)


                    img.Dispose()

     

    next x

     

    Can anyone show me how to use the addrange method.

     

    Any clue is VERY MUCH appreciated.

     

    Thanks,

     

    Thursday, June 16, 2011 2:00 PM
  • For anyone who is interested.
    I have made a list view in Win-32.
    I noticed that after listing for a view hours the listing becomes slow.
    So when the list becomes longer the AddItem became slower.

    ListView_SetColumnWidth(GetDlgItem(hWnd,IDC_LIST), colnum, LVSCW_AUTOSIZE | LVSCW_AUTOSIZE_USEHEADER);

    After removing the "Autosize" command the Additem did not become slower when the list became longer.
    So I think "Autosize" is performed on the complete list each time it is called.

    Regards

    Monday, December 3, 2012 4:14 PM