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
