ListView Performance

Dear community:

I have started a new feedback item on the MSDN Product Feedback center about the poor performance of ListView databinding in ATLAS.

Please view the details here:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=176826

I encourage you to view the feedback and comment and share your experiences. I believe this to be a major problem with ListView and, indeed, the way databinding happens in ATLAS on the client side (due to the MarkupParser.parse() method being called for each data item).

If you do not experience these problems, then please comment on that feedback item and let Microsoft (and me!) know in case this might be a special-case problem only for some browsers/installations.

I appreciate your time in this matter and I hope this will make ATLAS and even better product!!

Hi,

I completely agree with you. ListView is too slow to load.
Displaying 50 records takes forever.

I realized this problem when I started the development way back in April 2006. But continued using Atlas in the hope that performance will improve in the coming CTPs. Now the code is in production and the users have been complaining that Listview takes lot of resources (CPU: 100%) and lot of time to display.

I haven't tried using the AJAX RC because of the breaking changes involved. The other option for me is to use the Gridview server control.
Either way its rework for me.

Hoping that Microsoft Team will release a fix for the CTP version.

Regards,
Tim

I'm very new to the ListView, just a few experiments so far but I did notice (for my 10 records) that, strangely, athough I was using ListView to render a table (which will usually not display until fully loaded) the table would appear incrementally, the table headers, then with a couple of rows, then a couple more, finally the entire 10 rows.

I was taken aback that the data was not converted to a "rendering object" (ie an entire table) THEN rendered to screen, it seemed to do a bit, render, do a bit more, render etc etc.

Usually I've found Databinding to always be faster than manually looping through records and adding the results to a list. In THIS case, I suspect the opposite would be true, the only thing the databinding is giving you is the ability to define Template objects and databind in one line of code without iterating.

hello.

though i haven't looked at it for some time, i think that the erndering is done from x to x rows which are then inserted on the screen...

Would be consistent with my observations, but seems like a strange way to do it. For example, if you were rendering a 3D game image, you wouldn't render X polygons, swap the display buffers, then take the previous rendering, add a X more polys, swap the buffers agaim, until finally you had an entire frame image, it would be unthinkably slow. So why do it here? Seems like a hack to get around slow code? If that's the case I would think that a fix will be hard because it means that the way it's done is fundamentally slow, and has already been "optimised" with this "do a bit, render, do a bit more, render" algorith.

hello.

well, they'er still in the future bits. btw, i think that the way to go is to use pagination and render them all at once (maybe changing the ui so that it is only shown when data is present - while it isn't, i think that showing an animated gif is more than enough).

On further analysis, I found that the listview performs much better on Mozilla FireFox than on IE 6.
So, I guess, the problem could be with IE's javascript engine rather than with the ListView itself.

Regards,
Tim