harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Thu, 18 Oct 2007 10:29:15 GMT
Vladimir Strigun wrote:
> I'm a little bit confused about the results.

and I'm confused by your numbers below<g> so we match

> I tried to run the test (slughtly modified) on DRLVM and got the next results:

Let me just chop out the class name to make it more readable...

> Decoding time(j): 2844 millis
> Decoding time(j): 1797 millis
> Decoding time(j): 1578 millis
> Decoding time(j): 1203 millis
> Decoding time(j): 1125 millis
> Decoding time(d): 5328 millis
> Decoding time(d): 1906 millis
> Decoding time(d): 797 millis
> Decoding time(d): 609 millis
> Decoding time(d): 672 millis
> 
> Input length were 8 bytes, 128, 8kb, 16k and 128k correspondingly.

Though presumably in the opposite order, i.e.

Decoding time(j): 2844 millis for 128k =  22 ms/kb
Decoding time(j): 1797 millis for  16k = 112 ms/kb
Decoding time(j): 1578 millis for   8k = 197 ms/kb
Decoding time(j): 1203 millis
Decoding time(j): 1125 millis really took >1sec for 8 bytes?! no...

Decoding time(d): 5328 millis for 128k =  42 ms/kb
Decoding time(d): 1906 millis for  16k = 119 ms/kb
Decoding time(d):  797 millis for   8k = 100 ms/kb
Decoding time(d):  609 millis
Decoding time(d):  672 millis


> (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.

Non of the (j) numbers look good for small input, clearly I have
misunderstood.

Regards,
Tim

Mime
View raw message