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. http://javaglue.com/javaglue.html#tag:Ssx https://code.google.com/p/super-simple-xml/ )
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.
sdw
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<[email protected]>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
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
