http://bugs.winehq.org/show_bug.cgi?id=14303
--- Comment #7 from Igor Tarasov tarasov.igor@gmail.com 2009-07-24 11:25:01 --- Sorry for not responding quickly, I had to bring up testing environment.
(In reply to comment #5)
(In reply to comment #4)
With LVS_OWNERDATA it takes forever to select all (or partially) list in ~200 thousands items.
What about notifications here? Is this broken or not?
How can I be sure if that is broken or not, if I have never seen specs on these? I've looked through MSDN but have not found any notions regarding LVS_OWNERDATA.
Patch author completely removed notifications, that's why this solution is invalid.
But that does not make BUG invalid. The FIX is broken, not bug-report.
If slowdown is in a huge amount of messages it can't be fixed in listview and is a general messaging performance issue.
This can't be so. I've just checked that in windows with the same huge listview and it works immediately. It's like it was with bug #12701.
BTW, Igor, could you try to disable notifications in set_main_item() function:
It helped, but only a bit. It's still very slow.
BTW, another issue found here: there is even more noticeable slowdown when you click some item after you have selected them all (that is when all items get unselected).
I don't have enough time now, could you produce something like a benchmark (compilable on linux, as a crossbuild too)? Then we could profile it to find where we spend most of the time.
I think that I do not understand well what I need to do.
(In reply to comment #6)
Apparently LVS_OWNERDATA performance could be improved. It sends only one notification on select all case. Test sent: So, 200 thousands it will reduce from 400000 messages to 1.
Well, I see that your test case is for select all case only. But you should know that there is huge difference in performance not only in select all, but also in partial selects.