On 17 Sep 2008, [EMAIL PROTECTED] wrote: > Isn't this a bit absurd? Maybe I'm missing something but all I can see > is that your code adds these two optimizations: > > 32 - variable -> const > hashcode >> variable -> hashcode >> const
The hashcode is also used in the inline function RT_READ_SLOT. I added the asserts to protect against error on my part in this implementation. They can be removed if there are no reported problems. However, I was also unsure whether the URN lookups are supported? The splitting of the URN case is also a fairly large gain. For a non-URN lookups, there is only one branch (if versus if/else). Non-URN seems to be the most common form of query; this test can be moved to the caller which can be constant over the node iteration. A call through a function pointer is not usually that big a hit (there was a function call to a fixed address already). Not having a has_urn variable also seems to decrease register pressure. The code size is very small compared to the 2-256k tables. Try objdump -S qrp.o to see the code size difference between qrp_can_route_default and the macro code. For cases like 'qrp_can_route_16', shifts are not always needed as 32/16/8 bit manipulation can accomplish some of the work. The 'qrp_can_route_16' is the most common case in any runs I have observed. Also not the frame addressing [on x86 like -0x15(%epb)]. In the macro version, most variables are in registers. Regarding the temperature, I do not take it to be completely accurate. However, all three temperature sensors have decrease by similar amount. Eight degrees is significant. If it were two or three degrees it would not be; I realize they are not high precision instruments. The clock frequency reported by 'powertop' would also have be out (and gprof, etc). I am looking into disabling the frequency switching to get more accurate numbers via vmstat and top. However, it is still beneficial to know if it performs better on PPC, etc. Sorry about the C++ comments. Emacs did that automatically. 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