http://bugs.winehq.org/show_bug.cgi?id=14303
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2009-07-21 06:02:47 --- (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? For me the possible reason for ownerdata slowdown is a lot of notification messages to be sent.
(In reply to comment #3)
After that's a potential WONTFIX (or INVALID maybe) for me.
Why? This operation is really way too slow.
If we're broken in notification code it's another bug. Patch author completely removed notifications, that's why this solution is invalid.
If slowdown is in a huge amount of messages it can't be fixed in listview and is a general messaging performance issue.
BTW, Igor, could you try to disable notifications in set_main_item() function: --- if (notify_listview(infoPtr, LVN_ITEMCHANGING, &nmlv)) --- if (infoPtr->bDoChangeNotify) notify_listview(infoPtr, LVN_ITEMCHANGED, &nmlv); --- and report if it improves anything?
Another reason could be that I switched to store selection and focus flags in main item state (in main dpa) instead of resync it after and before sorting. This change improved sorting and made code more clear. I don't think another offset, dereferencing and assignment I've added to store it changed things a lot.
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.