This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: libgcj performance: _Jv_LookupInterfaceMethod
- To: Kresten Krab Thorup <krab at daimi dot au dot dk>
- Subject: Re: libgcj performance: _Jv_LookupInterfaceMethod
- From: Tom Tromey <tromey at cygnus dot com>
- Date: Wed, 17 Nov 1999 23:16:01 -0800 (PST)
- Cc: Jeff Sturm <jsturm at sigma6 dot com>, java-discuss at sourceware dot cygnus dot com
- References: <3821C65A.F00618DA@sigma6.com><xz666z1rvlg.fsf@ariel.daimi.au.dk>
>>>>> "Kresten" == Kresten Krab Thorup <krab@daimi.au.dk> writes:
Kresten> I think that you should be using `%' and not `&' to limit the
Kresten> hash code to be in the method cache index range.
You're right. Actually, I want to use "&" and require that the hash
table be the right length. Ordinarily I don't micro-optimize like
this, but I think in this case it will pay off.
Kresten> The bug in the original code was (I believe), that I forgot
Kresten> to reset method_cache_count after it was cleaned out. It
Kresten> should have been set back down to zero (in
Kresten> _Jv_AddMethodToCache). My hunch is, that fixing this bug
Kresten> will make it perform better than what's there now.
I'm reluctant to introduce a loop here without data supporting it one
way or another. It seems like it would only be useful when there are
many hash collisions.
Tom