[Bug 14303] Listview: select all is incredibly slow.

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=14303





--- Comment #5 from Nikolay Sivov <bunglehead at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.