On Wednesday 26 July 2006 13:03, Anton Luht wrote:
Hello,
One of possible candidates for such optimization may be for example
String.hashCode() . Current implementation is rather common. Wikipedia
points to hash functions that look more advanced (
http://en.wikipedia.org/wiki/Hash_function
Hello,
Seems to me that String.hashCode() has to use the algorithm described in the
spec if it's to be compliant.
Sorry, I didn't notice that the algorithm for hashCode() for String is
explicitly written in the spec. Thank you for pointing this. Yes, we
must follow spec in this case.
--
2006/7/27, Denis Kishenko [EMAIL PROTECTED]:
2006/7/27, Nathan Beyer [EMAIL PROTECTED]:
The serialized form is part of the public contract and we strive to meet all
parts of the public contract, so if you know of specific cases, please log
some issues about them. There are a few exceptional
2006/7/27, Denis Kishenko [EMAIL PROTECTED]:
2006/7/26, Alex Blewitt [EMAIL PROTECTED]:
There are other approaches that could be used instead of this. For
example, the value of the hashCode could be cached in a private
variable and then invalidated when any setValue() methods are called.
One
It was to strong when called this is as problem. Actually our and RI
implementation of Polygon can produce different serialization
binaries sometimes, in spite of this binaries can be read by both
implementations. So serialization compatibility should be correct.
2006/7/28, Alexey Petrenko
28 Jul 2006 16:03:33 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1B3 day of Apache Harmony Anton Luht wrote:
On 7/27/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Sounds great to have a page with algorithms tricks used in Harmony project!
Maybe it's worth to put information about algorithms to
On 7/27/06, Nathan Beyer [EMAIL PROTECTED] wrote:
What class are you referring to? The hash value of a String isn't written
during serialization [1]; the String serialization is actually a somewhat
special form. In most other classes that are serializable though, the hash
value generally isn't
2006/7/26, Alex Blewitt [EMAIL PROTECTED]:
On 26/07/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Frequently hash code is a sum of several other hashes. Such implementation
kill hash idea, it's terrible.
I agree that simple addition is not a good thing. However, exclusive
or can work just as
2006/7/26, Alex Blewitt [EMAIL PROTECTED]:
There are other approaches that could be used instead of this. For
example, the value of the hashCode could be cached in a private
variable and then invalidated when any setValue() methods are called.
One could even imagine a superclass performing this
2006/7/27, Nathan Beyer [EMAIL PROTECTED]:
The serialized form is part of the public contract and we strive to meet all
parts of the public contract, so if you know of specific cases, please log
some issues about them. There are a few exceptional cases, like TimeZone,
that may be incompatible,
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 26, 2006 7:25 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [optimization] Algorithmic tricks
Mikhail, you are right, in some places it can be very critical.
Now HashCode works only
2006/7/27, Ivanov, Alexey A [EMAIL PROTECTED]:
It can handle Objects and uses object.hashCode().
Yep, HashCode has been already doing this.
combine() performs the calculations. append() is a convenience method
that returns the object it was called upon, so that your example can be
re-written
On 7/26/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
There are a lot of algorithmic tricks in graphics module (awt, geom). But
as
I understand this module hasn't been integrated yet completely. By the way
does anybody there has experience and is interested in graphics
algorithms?
I do
On 7/27/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Sounds great to have a page with algorithms tricks used in Harmony project!
Maybe it's worth to put information about algorithms to Wiki :
http://wiki.apache.org/harmony/ ?
--
Regards,
Anton Luht,
Intel Middleware Products Division
On 7/27/06, Anton Luht [EMAIL PROTECTED] wrote:
On 7/27/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Sounds great to have a page with algorithms tricks used in Harmony
project!
Maybe it's worth to put information about algorithms to Wiki :
http://wiki.apache.org/harmony/ ?
+1
--
Regards,
+1
2006/7/27, Anton Luht [EMAIL PROTECTED]:
On 7/27/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Sounds great to have a page with algorithms tricks used in Harmony project!
Maybe it's worth to put information about algorithms to Wiki :
http://wiki.apache.org/harmony/ ?
--
Regards,
Anton Luht,
2006/7/27, Ilya Okomin [EMAIL PROTECTED]:
As for this thread I would suggest next tactics: to state issue here (thread
is a kind of a list of issues) and initiate issue discussion in separated
thread if it is worthy of it. Otherwise one unfinished trick discussion will
get lost behind the more
Hi all
There are a lot of algorithmic tricks in graphics module (awt, geom). But as
I understand this module hasn't been integrated yet completely. By the way
does anybody there has experience and is interested in graphics algorithms?
I do =)
I can recommend
Hello,
One of possible candidates for such optimization may be for example
String.hashCode() . Current implementation is rather common. Wikipedia
points to hash functions that look more advanced (
http://en.wikipedia.org/wiki/Hash_function ).
--
Regards,
Anton Luht,
Intel Middleware Products
On 7/25/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,
I'd like to suggest people that know some algorithmic tricks to look
at the corresponding areas of classlib. Maybe some of the community
members had (un)lucky experience of tuning performance of some
application that led them to a deep
I have watched over 100 hashCode implementations.
Frequently hash code is a sum of several other hashes. Such implementation
kill hash idea, it's terrible.
Here is some examples
public int hashCode() {
int result = 0;
IteratorMap.EntryK, V it = entrySet().iterator();
Some hashCode functions are actually very *hot* methods (e.g. String)
In this case I think that a bad but fast hashCode() could be better than
good but slow. May be I'm wrong but only tests can show the difference.
So if you have tests, I'm +1
On 7/26/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Mikhail, you are right, in some places it can be very critical.
Now HashCode works only with primitive types int, long, float, double,
boolean and doesn't override String.hashCode(), so don't care about strings.
Actually I don't understand the purpose of *combine()* method. I suppose we
can
Denis Kishenko wrote:
lurker-mode-off
Example of using
public int hashCode() {
HashCode hash = new HashCode();
hash.append(m00);
hash.append(m01);
hash.append(m02);
hash.append(m10);
hash.append(m11);
hash.append(m12);
On 26/07/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Frequently hash code is a sum of several other hashes. Such implementation
kill hash idea, it's terrible.
I agree that simple addition is not a good thing. However, exclusive
or can work just as well, as can a simple multiplication of
On 26/07/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Some hashCode functions are actually very *hot* methods (e.g. String)
In this case I think that a bad but fast hashCode() could be better than
good but slow. May be I'm wrong but only tests can show the difference.
So if you have tests, I'm +1
2006/7/26, Krzysztof Sobolewski [EMAIL PROTECTED]:
How about
return Arrays.hashCode(new Object[] {x, y, name});
?
Short, concise, a bit allocation-heavy (esp. for primitives (boxing)), but
for non-critical hashes should be fine.
/lurker-mode-off
Yep, good and simple way.I have already thought
-Original Message-
From: Mikhail Fursov [mailto:[EMAIL PROTECTED]
On 7/27/06, Alex Blewitt [EMAIL PROTECTED] wrote:
What effect would there be if we were communicating (via RMI) with an
implementation of a remote VM that isn't harmony? I.e.,if we have a
String asdfasdfasdf
On 7/25/06, Anton Luht [EMAIL PROTECTED] wrote:
For example, consider current implementation of
java.util.BitSet.cardinality() . It just checks all bits one by one
and increments count. [1] Gives an overview of algorithms for checking
set bit count. The fastest algorithms are with table lookup,
Anton,
it looks like a joke but while investigating potential performance problems
of our classlib with DeCapo benchmark I found that the same method (counting
signed bits in bitset) is the hottest method in antlr benchmark. But this
method is not from classlib, but from the benchmark and its
30 matches
Mail list logo
