On 10/18/07, Tim Ellison <[EMAIL PROTECTED]> wrote: > 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
Sorry, it seems my results more confusing for you :) I hope this looks better: Decoding time(j): 2844 millis for 8bytes (3000000 iterations) Decoding time(j): 1797 millis for 128bytes (800000 iterations) Decoding time(j): 1578 millis for 8k (20000 iterations) Decoding time(j): 1203 millis for 16k (8000 iterations) Decoding time(j): 1125 millis for 128K (1000 iterations) Decoding time(d): 5328 millis for 8bytes (3000000 iterations) Decoding time(d): 1906 millis for 128bytes (800000 iterations) Decoding time(d): 797 millis for 8k (20000 iterations) Decoding time(d): 609 millis for 16k (8000 iterations) Decoding time(d): 672 millis for 128k (1000 iterations) Thanks. Vladimir. > > > (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 >
