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>
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lang] CharUtils.isAscii methods and CharSet, two issues
Date: Thu, 18 Mar 2004 17:37:32 -0500
Message-ID: <D1639D06CFBD014F87F3978DA7038B934B6A9A@ns1017.SSSI.seagull.nl>
Thread-Topic: [lang] CharUtils.isAscii methods and CharSet, two issues
Thread-Index: AcQHs8+mcakft0XOSc+8gGLLcszGugAANW2AAWELXuA=
From: "Gary Gregory" <ggregory@seagullsw.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

Well I have some interesting numbers, to say the least.

Saying that comparing CharSet to CharUtils make CharSet look bad is an
understatement. Obviously there is room for improvement there.=20

What is more interesting albeit tangential, is the performace
improvement from Sun 1.3.1_10 to 1.4.2_04, and even more dramatic within
1.4.2_04, between the client and server VMs.=20

I've saved the CharUtilsPerfTest class in CVS for those of you who'd
care to track this issue.

Now: Thu Mar 18 14:29:48 PST 2004
Sun Microsystems Inc. Java(TM) 2 Runtime Environment, Standard Edition
1.3.1_10-b03
Sun Microsystems Inc. Java HotSpot(TM) Client VM 1.3.1_10-b03
Windows XP 5.1 x86 pentium i486 i386
Do nohting: 0 milliseconds.
run_CharUtils_isAsciiNumeric: 4,545 milliseconds.
run_inlined_CharUtils_isAsciiNumeric: 3,417 milliseconds.
run_inlined_CharUtils_isAsciiNumeric: 85,679 milliseconds.


Now: Thu Mar 18 14:24:51 PST 2004
Sun Microsystems Inc. Java(TM) 2 Runtime Environment, Standard Edition
1.4.2_04-b05
Sun Microsystems Inc. Java HotSpot(TM) Client VM 1.4.2_04-b05
Windows XP 5.1 x86 pentium i486 i386
Do nohting: 0 milliseconds.
run_CharUtils_isAsciiNumeric: 2,578 milliseconds.
run_inlined_CharUtils_isAsciiNumeric: 2,477 milliseconds.
run_inlined_CharUtils_isAsciiNumeric: 114,429 milliseconds.

Now: Thu Mar 18 14:27:55 PST 2004
Sun Microsystems Inc. Java(TM) 2 Runtime Environment, Standard Edition
1.4.2_04-b05
Sun Microsystems Inc. Java HotSpot(TM) Server VM 1.4.2_04-b05
Windows XP 5.1 x86 pentium i486 i386
Do nohting: 0 milliseconds.
run_CharUtils_isAsciiNumeric: 630 milliseconds.
run_inlined_CharUtils_isAsciiNumeric: 709 milliseconds.
run_inlined_CharUtils_isAsciiNumeric: 84,420 milliseconds.

Gary

> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> Sent: Thursday, March 11, 2004 14:04
> To: Jakarta Commons Developers List
> Subject: RE: [lang] CharUtils.isAscii methods and CharSet, two issues
>=20
> I'll write up a little test over the weekend if not sooner.
>=20
> > There are lots of good changes that don't add any functional
> improvement
> > at the machine level, but a more OO solution may very well improve
> > things at the maintenance and class heirarchy level.
>=20
> This is what I am striving for.
>=20
> Gary
>=20
> > -----Original Message-----
> > From: matthew.hawthorne [mailto:matth@apache.org]
> > Sent: Thursday, March 11, 2004 13:56
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] CharUtils.isAscii methods and CharSet, two
issues
> >
> > Todd V. Jonker wrote:
> > > As is stands, isAsciiAlphaUpper follows
> > > DoTheSimplestThingThatCouldPossiblyWork but (perhaps) breaks
> > > OnceAndOnlyOnce.
> > >
> > > Still, I think the existing code is better.  Such things tend to
be
> > > called inside tight inner loops, and as such every bytecode
counts.
> > Your
> > > suggested rewrite adds no functional improvement while increasing
> the
> > > execution time manyfold.  I strongly suggest leaving it as-is.
> >
> >
> > I think that running some performance tests would provide the best
> > insight into possible effects on execution time.  Gary, maybe you
> could
> > write a small test to see if this change truly would cause a
> performance
> > problem?
> >
> > There are lots of good changes that don't add any functional
> improvement
> > at the machine level, but a more OO solution may very well improve
> > things at the maintenance and class heirarchy level.
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20


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