tree/list-view slowness

[James Hawkins]

I am currently working on making Kazaa Lite 2.4.3 more usable.  The
most major problem remaining is that when the user chooses to search
for a file on the network, the program slows almost to a halt and
becomes mostly unmanageable.  The results are displayed in a
tree/list-view in the right pane [1].  I've looked into both of the
controls, and it seems like the slowness could be coming from their
implementation, but even when I set comctl32 to native, the problem
remains.  Also, I've done a trace+treeview and a trace+listview and
only treeview api's seem to be called and not listview.  Would it be a
possibility that they implemented their own listview?  Can anyone
describe a method I can use to track down the inefficiency?  Thankyou
for your help.

[1] http://www.andrew.cmu.edu/user/jhawkins/klite.jpeg

[Mike Hearn]

James Hawkins wrote:
> I am currently working on making Kazaa Lite 2.4.3 more usable.  The
> most major problem remaining is that when the user chooses to search
> for a file on the network, the program slows almost to a halt and
> becomes mostly unmanageable.  The results are displayed in a
> tree/list-view in the right pane [1].  I've looked into both of the
> controls, and it seems like the slowness could be coming from their
> implementation, but even when I set comctl32 to native, the problem
> remains.

Well, if native comctl32 is also slow then it's probably not the 
treeview/listview code. From the screenshot there don't seem to be that 
many results, I'd be surprised if any treeview control no matter how 
badly implemented choked on only a couple of screenfuls of data. The 
problem is probably elsewhere.
> Also, I've done a trace+treeview and a trace+listview and
> only treeview api's seem to be called and not listview.  Would it be a
> possibility that they implemented their own listview?  Can anyone
> describe a method I can use to track down the inefficiency?  Thankyou
> for your help.

I don't see any listview in the screenshot, only a treeview. But yes 
programs reimplement the common controls all the time, it wouldn't be 
surprising.

You could try oprofile if you're on a 2.6 kernel, alternatively just try 
hacking bits of code out of Wine to see when things speed up. If the 
slowness is in adding the results rather than rendering them, perhaps 
it's a message passing speed problem? If the slowness is in rendering 
them maybe owner-draw is being used so there is still lots of message 
passing going on.

thanks -mike