Lloyd Bryant wrote: > No sort: 3.77 sec (0 ms avg sort time) > g_slist_sort: 3.83 sec (18.29 ms avg sort time) > sort_slist_with_qsort: 3.77 sec (10.79 ms avg sort time)
Did you use a corrected version of the qsort() variant? Otherwise, the last result is bogus. > I'm currently setting up another test, using 100,000 files. I want to see > how sort time grows for the different sorting methods. It took 20 minutes > to do the initial directory scan (directories not in cache, I guess), and > I'm still waiting for the SHA1's to build so I can do the real testing. You might want to create a fake sha1_cache to speed things up. > The initial code, which started SHA1 calculations before directory scanning > was complete, was actually a better solution for large numbers of files. It > takes a LONG time to complete the directory scan, and having the SHA1 > calculation routine setting idle during that time doesn't make a lot of > sense. I'm not sure whether it would really run the SHA-1 calculation in the background whilst scanning. I was rather surprised to notice that the Gtk-Gnutella doesn't stall during the scan. There are some periodic calls to dispatch Gtk+ events to keep the GUI responsive but it seems I/O is dispatched as well. I believe this wasn't always the case. Either Gtk+/GLib changed or that's the result of using kqueue|epoll|/dev/poll instead of the GLib stuff. That's also the reason the you see the warnings when calling rescan from the shell. The shell commands are directly executed from the even dispatch callback. I'm not sure whether this can be ignored or whether the shell commands should rather be enqueued to prevent recursion. > Second, the SHA1 calculation does not use enough CPU. Right now, I'm > waiting for the SHA1's to complete - CPU (user + system) is running at about > 5% (I have that machine offline, so there's no network load on it at the > moment). One flaw of Gtk-Gnutella is that it cannot really take advantage of multi-core or multi-processor machines except that the X11 server might be running on different one. Normally, one would have splitted the GUI from the core right from the start. Now we have the issue that the core can stall the GUI and worse vice-versa. Threads in C are uglier than hell but I could imagine doing the SHA-1 calculations in a secondary process. We'd give that process (almost) idle priority. That way the OS scheduler does the dirty work and we can utilize another core. I'd prefer to do fork() + exec() instead of just fork() so that we don't unnecessarily use virtual memory also because that looks scarier in "top" than it actually is. On an unrelated note, we could also kill the ADNS helper after some timeout and fork()+exec() another when we need it again, simply because DNS lookups are typically rarely needed, so keeping it around all the time looks somewhat sloppy. -- 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
