Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Sat, 24 May 2003 07:47:59 -0700
From: Alex Chaffee / Purple Technology <guru@stinky.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: [lang] Optimizing Entities
Message-ID: <20030524074758.C880@stinky.com>
Reply-To: alex@jguru.com
References: <245A7290F0E0D311BF6E009027E7908B0720452F@atlanta.seagullsw.com>
 <20030523201418.B880@stinky.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030523201418.B880@stinky.com>;
 from guru@stinky.com on Fri, May 23, 2003 at 08:14:18PM -0700

I've taken a stab at performance testing Entities.  I've added three
different implementations of the internal map as inner classes:
HashIntMap (which works the same as before and uses HashMaps to store
the name-to-value and value-to-name lookups), TreeIntMap (uses
TreeMaps), and ArrayIntMap (a simple, minimal array-based store, using
linear lookup).

I also wrote a class EntitiesPerformanceTest as a JUnit TestCase.
Since I use the new version of IDEA, which times test methods and
displays the results in a pretty table, I found this a very convenient
way to run the test.  (It's not in the LangTestSuite, nor should it
be.)  I notice that the version I checked in uses a string of size
1000 and 200 test runs each, but I was using values of 10000 and 1000
for my real tests.

The string created looks like this: "xxxx&fnof;xxxx&Alpha;xxxx..."  My
idea was that this would represent the most common use case.  It turns
out that lookup performance on escape is slowest (for arrays at least)
when the character is not found, since it has to walk the whole array,
so I wanted to be sure to stack the deck so this would be revealed.

The results are not surprising: HashMap performs best, even with the
new Integer being created on every call.  So it doesn't go any faster
yet.  Also, unescaping is vastly quicker than escaping, since to
unescape, you scan the string for & characters and essentially get to
skip over 4/5 of the data.  Also, unescaping seems to be almost
completely insensitive to lookup method, which is a little confusing
-- I wonder if Gary's JPerfmeter can shed any light on why this is so.

I'll work on an int-array-based binary lookup next.

-- 
Alex Chaffee                               mailto:alex@jguru.com
Purple Technology - Code and Consulting    http://www.purpletech.com/
jGuru - Java News and FAQs                 http://www.jguru.com/alex/
Gamelan - the Original Java site           http://www.gamelan.com/
Stinky - Art and Angst                     http://www.stinky.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org