harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Strigun" <vstri...@gmail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Wed, 17 Oct 2007 21:58:15 GMT
On 10/17/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Tim Ellison wrote:
> > (Left as an exercise for the reader <g>)
>
> Feeling a bit guilty about the cop-out...
>
> I slightly modified Alexei's test case to
>  - include some warm-up encode/decode loops to get the methods
>   jitted to a reasonable level,
>  - read the data into a direct byte buffer, and then into a
>   'regular' byte buffer, e.g. one allocated in the Java heap,
>  - I then looked at the effect of converting a short string (129 chars)
>
> I was running this on the IBM VME, and here's what I got (below).
>
> Interestingly the Java decoder was faster on the long string than the
> native code.  The others are sufficiently similar to imply to me that we
> should just keep it all in Java.
>
>
> === long string
>
> Read chars = 3285165
> 10 loops warm up
> 10 loops timed
>
> Direct ByteBuffer
>
> Built-in
> <org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 781
> millis
> <org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 571
> millis
>
>
> Java Heap Byte Buffer
>
> Built-in
> <org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 430
> millis
> <org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 521
> millis
>
>
> === short string
>
> Read chars = 129
> 1000 loops warm-up
> 10000 loops timed
>
>
> Direct ByteBuffer
>
> Built-in
> <org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 10
> millis
> <org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 0 millis
>
>
> Java Heap Byte Buffer
>
> Built-in
> <org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 10
> millis
> <org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 0 millis
>

I'm a little bit confused about the results.
I tried to run the test (slughtly modified) on DRLVM and got the next results:
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
2844 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1797 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1578 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1203 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1125 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
5328 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
1906 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
797 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
609 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
672 millis

Input length were 8 bytes, 128, 8kb, 16k and 128k correspondingly. (j)
means java buffer, (d) - direct byte buffer. It seems that native
decoding faster for big buffers, whereas Java part works fine for
small input.

Thanks.
Vladimir.

Mime
View raw message