Lloyd Bryant wrote: > >Did you use a corrected version of the qsort() variant? Otherwise, the > >last result is bogus.
> Since the qsort results are almost half of the slist results, I'm assuming > that I'm using the right version (your message mentioned taking LONGER). Well, with the bad version there's no defined behaviour. It could be faster, slower or just crash. It probably didn't crash because the sorting routine is very simple and only reads memory. If I had added shared_file_check() right away, I would have noticed my mistake immediately. > I've been using pthreads for years - it isn't really that difficult to work > with them. Though it would be a MAJOR headache taking a large app like GtkG > and converting it to multithreading - multithreading is only easy if the > program is designed for it from the beginning. Sure, if the thread do not allocate any resources but simply do safe stuff like calculations using their local data, there's no problem. However I think once you've enabled multi-threading you get a penalty for many functions that have to use locks and mutexes then whether they are ever used concurrently or not. Maybe that's completely neglible. As long as it works and is as portable as now, I don't really mind. > Dbus seems to offer a better solution. I'm no expert on that subject, but > >from what I can see the Dbus daemon is capable of starting programs on an > "as-needed" basis. Thus, whenever a "calculate SHA1" method is called, the > daemon would start a process to handle it, and that process could terminate > when there's no more work for it to do. That process could run with a nice > of +19, so would grab as much of the free CPU as it can without having much > effect on any other processes. Well, Gtk-Gnutella compiles against D-Bus if it's available albeit it's hardly used for anything. It's basically just a proof-of-concept for now. As long as I'm not convinced that D-Bus does something that I cannot easily do myself, I wouldn't like to make it a dependency for Gtk-Gnutella. What I have in mind is fairly simple I believe and can be generalized so it can be shared between both ADNS and ASHA1 and maybe other stuff in the future. > There's no reason that the UI and core can't exists as separate processes as > well, passing info between them via Dbus. I started looking at Dbus for > this reason - my headless box doesn't have X11 installed (not enough CPU > power for a modern desktop anyway), but I would like to have GtkG's core > running there, and be able to connect a GUI running on another machine to > it. The remote shell just isn't up to the job (and I've noticed that it's > marked as "deprecated" anyway). It is deprecated in so far that I'd like to remove ability to connect to it over TCP. If we utilized GNU TLS for the authentication, I'd reconsider this but this authentication cookie goo is a pretty bad idea in the long run because it cannot be used safely. With WLAN, internet cafes and whatnot there's too much of a danger that someone sniffs the connection and obtains this cookie. For localhost that doesn't matter but in that case you can simply use the unix domain socket. The shell itself will stay though. Of course I don't plan to abuse the shell for GUI<->Core IPC. A unix domain socket would be fine for that though. > -------------------------------------------------------------------------- > I've finished my 100,000 file test. There are 4 data sets this time - my > patch (no sort), my patch (g_slist_sort), my patch (with your > sort_slist_using_qsort function), and finally with the code from the SVN > (r12351): > > No sort: 21.3 sec (0 ms sorting) > g_slist_sort: 21.2 sec (475ms sorting) > sort_slist_with_qsort: 21.1 sec (128ms sorting) > SVN r12351: (393ms sorting) You could check whether replacing qsort() with mergesort() improves performance. In the general case it shouldn't but it might for the common case here. Also, I don't see how sorting a list should be faster than sorting an array because the former actually does the latter plus the conversion stuff. So I'd think you're using the buggy version. Or maybe it's the assertion check overhead. You could remove those shared_file_check() from the sorting function and see whether this causes a significant overhead. If you compiled without optimization or a P2 is much worse at branch-prediction etc. than my CPU these checks might really cause a severe performance penalty. After all, the assembler code is 10x as large with these two additional lines. > With these test results, sort_slist_with_qsort appears to be a hands-down > winner. Your current sort is somewhat faster than my original patch (17%), > but the sort_slist_with_qsort is WAY faster. Could we dig that version > back up, and verify that it's actually sorting the list - I didn't connect > to that machine and actually verify the sort results during my performance > tests. I verified the patch before I submitted it, but not the > sort_slist_with_qsort version. I'll check the corrected version. > P2-300 with 256Mb RAM: Processing 100,000 files: current SVN version uses > less than 0.4 seconds to perform the sort. Are we agreed that that machine > with that many files pretty much defines a worst-case scenario as far as > sorting performance is concerned? Since 99.9% or more of the time is spent actually scanning the directories, I can live very well with 0.4 seconds stalling. -- Christian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
