commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Williams <>
Subject Re: [pool] replacing numeric/byte constants with Java5 enums
Date Mon, 25 Apr 2011 22:24:01 GMT
Probably wrapped integers would also do badly.  The issue seemed to be that all object creates
and method calls were expensive, far 
more expensive than a final static int or array access.  The JDK magically transforms the
literal use of objects and methods into 
much faster, but equivalent code.  While Dalvik has a JIT from 2.2, it is not at the same
level yet.  In my first cut at the Ssx XML 
parser, I accidentally used Character where I meant char.  In the JDK, parsing 64K of XML
took 30 ms.  On 2.2 Dalvik, the equivalent 
run with unoptimized code took 65,000 ms.  Half of that was because I'd used Character instead
of char.  Easy fix.  Various other 
improvements brought it down to 300-400ms which is about the 1/10th speed of a desktop expected.
 And the result still ran in the 
same 30 ms. in the JDK.  (Ssx has a Sax parser in 240 lines of Java, and a DOM-like but more
concise Java-centric API in about 1000 
lines of Java.

Performance issues in Dalvik shouldn't necessarily affect all code written of course, but
it is something to avoid exacerbating in 
general purpose, likely to be popular libraries.

Perhaps maybe a little harder to explain: Enums should be avoided for certain uses.  The main
one I've run into is error codes: At 
least for multi-tier applications, this can make evolution and versioning resilience a headache.
 In particular, interfaces like 
Google Protocol buffers which tries to faithfully map Java enums through symbols and types
to an interpreted interface for 
serialization / deserialization create a requirement to be in perfect sync between two communication
partners.  This is sort of the 
opposite philosophy of XML in terms of loose coupling.


On 4/25/11 2:50 PM, Adrian Crum wrote:
> It would be interesting to see how an int wrapper would perform on Android.
> -Adrian
> On 4/25/2011 2:21 PM, Stephen Williams wrote:
>> Note that, as of Android 2.2's Dalvik at least, that Java5 enums are much much slower
than using constants.  For anything that 
>> gets used frequently, and that might be used on Android, that is a problem.  I wrote
and optimized a SAX and DOM parser on 
>> Android.  While the JDK will optimize out most of the overhead for enums and things
like Character objects rather than char, 
>> Dalvik won't (yet, as of 2.2 at least).
>> Another data point: For small sets with String as a key, TreeMap<> is much
faster than HashMap<>.  Makes sense when you think 
>> about it, but it was a surprise at the time.
>> Just FYI.
>> sdw
>> On 4/25/11 2:13 PM, Gary Gregory wrote:
>>> That would fall under the Java 5 umbrella, like generics, so that's OK with
>>> me for an ASAP pool2 release.
>>> Gary
>>> On Mon, Apr 25, 2011 at 4:40 PM, Simone Tripodi<>wrote:
>>>> Hi all,
>>>> in the first pool2 attempt we agreed on replacing numeric/byte
>>>> constants with Java5 enums, do we agree on doing it also for first
>>>> pool2 release?
>>>> Thanks in advance!
>>>> Simo

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message