Lloyd Bryant wrote: > Attached is a patch to have a "browse host" request respond with the files > sorted by descending file date/time (so that the newest files on the system > appear at the beginning of the browse list).
I've integrated your patch now. However, instead of sorting the list, I decided to sort file_table[]. Maybe this fixes the performance issue you've noticed. I didn't notice a significant difference but it shouldn't be slower in any case. I did this mainly because request_sha1() can cause to remove the file again but a NULL pointer in shared_files was handled elsewhere whereas holes in file_table[] are already expected. Removing a node from a GSList is a bit awkward albeit not really difficult but I consider sorting the table simpler and clearer. > As part of this change, it was necessary for me to move some things from > "recurse_scan_intern()" to "share_scan()", as I was having problems with > the SHA1 calculation routine relying on values that were set in > "recurse_scan_intern()" (Otherwise, I would have had to wait until all > SHA1's were updated before doing the sort - that could take a while). Yes, I noticed that request_sha1() uses the file index, so you can't easily change it after that. > I created a new property to determine whether or not this sort is > performed: "sort_browse_upload" (gboolean, of course). The property is > live and can be accessed via the preferences-debug screen (or the shell) or > the gnet_config file. If somebody has an exceptionally large number of > files, then the sort could potentially add a substantial amount of time to > the total required for a rescan (note: on my headless box, which is an > obsolete P2-300, processing 7600 files, having this option active adds > about 15 seconds to the time required for a rescan. Not too bad....) I've left this property out for now. There's a message printed that shows how long the sorting took. Look for "MESSAGE.*sorting took" after a rescan. If that shows that sorting took significantly longer than a second, I'll consider adding this part of your patch as well. > src/core/share.h By the way, whenever a function can be static, make it static. You can put a prototype at the head of the C file, if required. It's sometimes necessary for cyclic or recursive code paths. Otherwise, just put it above the first function that uses it. Additional prototypes just add noise and must be maintained as well. I sometimes even find prototypes for which no implementation exists anymore. Anyway, thanks a lot for you contribution once again! -- 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
