Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: HashHappy
Date: Tue, 29 Apr 2008 10:50:23 -0400
User-Agent: KMail/1.9.7
Cc: Fred Dushin <fred@dushin.net>
References: <EE55A5B5-36AE-41FF-BE35-AE12C2284C77@dushin.net>
 <61b5d9410804290726n46100202t5e992ad04bba77ea@mail.gmail.com>
 <F88CFE3C-E46B-4454-997C-C094660DA1DC@dushin.net>
In-Reply-To: <F88CFE3C-E46B-4454-997C-C094660DA1DC@dushin.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200804291050.23279.dkulp@apache.org>

On Tuesday 29 April 2008, Fred Dushin wrote:
> Performance measurements would certainly be in order, if a change were
> to occur.
>
> What I'm more concerned about is flushing out any ordering assumptions
> in collections that are inherently unordered.  That, and
> reproducibility of errors on Mac/Windows/Linux/etc

Actually, that brings up the other issue....  The LinkedHashMap and 
LinkedHashSet collections that provide order based on insertion order.   

Thus, for each replacement, you would need to determine what IS the order 
supposed to be if an order is supposed to be maintained.   If no order 
is specified, then it would need to drop to performance comparisons to 
see if a sorted version is better than a hash version.

Dan


> On Apr 29, 2008, at 10:26 AM, Benson Margulies wrote:
> > Fred,
> >
> > I'd be happy to profile any test case in which you think such a case
> > would
> > help. I'm not really spun up on profiling for working set as opposed
> > to CPU,
> > but I'm game to try.
> >
> > --benson


-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog