process usage problem with filling a large list view

  • Thread starter Thread starter Brian Henry
  • Start date Start date
B

Brian Henry

Well here is the problem, I have a data set with about 9,000 to 20,000
people in it in the data table "people"... I am then reading it into a list
view one at a time row by row... adding each person to the list view, well
this works fine up to about 1,000 people then it start's to get really show
putting the people in (a lot of process time used up)... does anyone know of
any optimizations i could do to make this processess work a lot faster?
thanks
 
Query analyzer in SQL Server tools seems to be able to load 90,000 people
records with out any problems at all... any idea how it works so fast? that
i could implement with a listview
 
I did that article already once, it is still very very slow with large
amounts of data... what I'm really looking for is an optimized version for
large (over 10,000 rows) of data.. essentially that example on MSDN is
adding items row by row also....

' load all subfields
For Field = 1 To mColumns.Count - 1
Item.SubItems.Add(GetField(InnerSource.Item(Row), _
mColumns(Field).Field).ToString)
Next
Items.Add(Item)


which is how mine is right now with the one I designed
 
copied the wrong piece of code in that example there, but you get the
idea... it's pretty much loading the list view row by row also from the data
set when its data bound
 
not really sure what that is, can you give me some more information? Is that
like how SQL Server EM loads as it needes it? If so I'm not sure how to
implement that.. thanks!
 
Sorta...

EM actually uses the API to draw what is needed onPaint. I'm pretty sure at
least (because it would appear to be doing so)

However, lets look at databinding for a second. Datasets / anything that
implements IBindingList emits an event called ListChanged, which databound
controls bind to to automatically invalidate/repaint the drawing area of the
control.

Now, this event gets fired EVERY TIME the list changes... so.. imagine with
your 10k+ records this event is being constructed and fired (because it does
have meaningful eventargs) that many times. So, your control has to
invalidate/repaint everytime...

by using suspendbinding, you dont' catch that ListChanged event, letting
your data fill normally and then when you resumebinding, it catches that
list changed event again. So, instead of repainting the surface 10k+ times,
it just repaints it once and each subsequent ListChanged event thereof.
Which you can imagine the cost savings on that.

Excuse my long tirades, as I'm sure Cor will point those out. =)

-CJ
 
* "Brian Henry said:
Well here is the problem, I have a data set with about 9,000 to 20,000
people in it in the data table "people"... I am then reading it into a list
view one at a time row by row... adding each person to the list view, well
this works fine up to about 1,000 people then it start's to get really show
putting the people in (a lot of process time used up)... does anyone know of
any optimizations i could do to make this processess work a lot faster?
Click to expand...

<http://www.ilypsys-systems.co.uk/ils1controls.zip>
 
Back
Top