gui hangs when searching for something that gives a lot of results

I believe the correct term would be "freeze". The gui is too busy processing the results to redraw. IIRC the core sends a dispatch on each search record packet, performance could probably be improved be sending larger bundles (this way the number of times to sort and do general treeview updating is reduced).

I can't really reproduce this, it's not slow to me. Razzloss says he cannot see it either. People on irc (with high-performance computers) still complain about this issue though. It would be good if someone found out what specific thing triggers the slowness.

I did? Anyway, it is possible to reproduce this. GUI freezes for a while with 7500 results (probably less, but that was what I got with "mp3 mp3 mp3" -search in a hub with 2500 users). Possible fixes are all unpleasant, I think, but I'll take a look with a profiler when I have time.

@individ: What gtk version are you using?

--RZ

You do? Well then, that's good. Actually the problem exists for me too, but it's not that huge performance loss that everybody else is talking about. 0-2 seconds, top. (It all depends on how many hits you get though) And my computer is several years old. I have an old patch that does exactly what I suggest in https://bugs.launchpad.net/linuxdcpp/+bug/302340/comments/2 But steven didn't think searching had any problems, so I dropped it.

i use linuxdc++ in my university campus where people are connected to each other through the lan (100mbps). hence searching for almost anything with a common term (like movie mp3 etc) freezes the gui for quite a long time (4- 6 secs).
the StrongDc windows client doesnt seem to have this problem and keeps on populating the search results page as more and more files are found matching the search term.
Can we do something similar, wherein the searching is done in a different thread, and as more and more results are found its appended to the results page. Sorting can also be tweaked so that it doesnt keep on sorting after every single matching entry is found(maybe after every 5 results or after every 5 secs or somethin), thereby saving precious cpu cycles.

I'm using the latest linuxdcpp in the ubuntu karmic repo (version: 1.0.3) and this problem is no longer present in it.
Good work devs.
thanks.

Razzloss, since you reproduced this previously can you confirm if this is resolved in latest trunk when you get a chance? I don't think we made any changes to resolve this...

The GUI no longer freezes and the delay has been reduced to 2 secs max.

This is definetely isn't fixed (in the 1.0.3 or in the latest trunk). Changes I've made for the bug #442475 seem to help a lot for the performance also.

With clean trunk debug build adding ~10000 results froze the UI for over 20 seconds. With the changes for #442475 debug build added the same amount of results in a few seconds (there was still somewhat noticable freeze). With ~28000 results I got tired of waiting for the clean trunk after 1,5 minutes, with #442475 changes it took about 10 seconds.

--RZ

When I assigned this to myself I was going to just commit the search regression fixes and call this one fixed as well. However I did some tests over the weekend with something similar to this (patch attached). Tested patch included some other changes (like swapping the guiFuncs vector with a working copy to reduce the need for guiFuncs locks, which reduce the need for _client functions to actually wait for the guiFuncs lock. Though I don't know if that is significant as processGui doesn't hold the lock that long. But that of course caused some lovely problems with deleteEntry).

Anyway processing the gtk events once in a while in the processGui thread helped to keep gui responsive with the cases where pending guiFuncs vector gets too long (joining many large hubs (though don't know if this is an issue still?), receiving search results ~10Mb/s). It doesn't help when single function call takes too long (eg. regrouping >10000 search results). The one thing I have no idea is if it is safe to call gtk_main_iteration inside the gdk_threads_enter? I didn't manage to deadlock it during testing, but that really doesn't tell anything.

Actually now that I think of it, probably some time based solution would be better instead of the call count proposed in the patch.

--RZ

10 - 20 sec GUI freeze is not so much important for me, i use linuxdcpp 1.1.0 and have similar bug. but it freeze all my desktop (or my session on x.org).

if i login on native console (ctrl+f1) and do 'killall linuxdcpp', this fix problem.

this bug appear if i click on link similar as magnet:?xt=urn:tree:tiger:3YNAR5Y5GU236PMN5NBLRBTI5RPIWMETCNEE4AY&xl=652804096&dn=Greys_Anatomy_8x01.avi

it can apperar from 2nd 3rd or 4th click.

can anybody reproduce it?

Please do not post links to copyrighted material.