Bill Pringlemeir wrote: > 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.
Yes, but the shifted hashcode isn't a constant, so RT_READ_SLOT() can hardly benefit from the constant shift value. > 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? For the moment being, they are still routed. gtk-gnutella in current SVN does not insert URNs in the QRT any longer, so URN queries can never match locally. LimeWire and derivatives haven't inserted URNs into the QRT for years. I believe they support single-hop URN queries though. > 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. Sure, but I think code cache much smaller than data cache. I wasn't trying to say that this is a problem with your optimization but it's a negative factor no matter how minor it may be. > 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. Are you compiling with any -march flag? I believe for most of the code optimizations are largely irrelevant but code like this will often benefit significantly from CPU-specific optimizations. -- Christian ------------------------------------------------------------------------- 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
