commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsw.com>
Subject RE: [lang] CharUtils.isAscii methods and CharSet, two issues
Date Fri, 19 Mar 2004 00:28:00 GMT
Yes, you are correct, I forgot to fix the paste!

gg

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, March 18, 2004 15:49
> To: Jakarta Commons Developers List
> Subject: Re: [lang] CharUtils.isAscii methods and CharSet, two issues
> 
> I'm guessing the long time version is CharSet ;-) We love cut and
paste.
> 
> Stephen
> 
> ----- Original Message -----
> From: "Gary Gregory" <ggregory@seagullsw.com>
> 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.
> 
> 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.
> 
> 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
> >
> > I'll write up a little test over the weekend if not sooner.
> >
> > > 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.
> >
> > This is what I am striving for.
> >
> > Gary
> >
> > > -----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
> > >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



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


Mime
View raw message