I have committed some changes to core/qrp.c (r15843), Change qrp_can_route to use a function pointer in the routing_table structure. Groups of route decision routines optimize for tables tables from 16k to 2M (corresponding to 14 to 21 bits), in URN and non-URN version are 'templated'. The fixed shift allows compilers to do a much better job of precomputing work.
Profiling indicates that the 2^16 and 2^17 are the most common tables sizes (most likely due to lime wire). However, all variants were left. The code size is very small compared to the table sizes. Also, the hottest routines will be cached. It may be more sensible to order the URN and non-URN together (same cache page). However, it seems that URN searches are very rare (not supported by LW?). Alternate data structures could be employed with the function pointer method. Sparse tables could be represented by a trees. Alternate function pointers could decode tables in either array format or tree format; However, the tree structure would trade time for space. My system has a dynamic clock [Intel Prescott]. The rates are 400, 800, 1200, 2400, 3200 MHz. Previously, the CPU would spend time in many of the ranges. With these changes, it is staying in the 400/800 MHz range (also 8deg C cooler). Top measurements are useless with a dynamic clock. 'gprof' also indicates an improvement. However, multiple measurements are probably best for performance improvements. If you have top numbers before/after getting r15843 as an ultra-node. It might be helpful to know if these changes should stay. Although, the changes should be architecture independent. Regards, Bill Pringlemeir. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
