hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ...

[Xueming Shen]

The gain from doing

int sr = src.remaining();
int dr = dst.remaining();

Ulf, thanks for looking into the changes.

It might not be a good idea to skip the temporary variable c in the 
loop, I'm not sure
it's a good idea to put an "un-mappable" char into the output buffer in 
case we have
a un-mappable though yes we don't not change the buffer position. This 
actually is
all most all the gain come from in -server vm case when I run my benchmark.

However in "client" vm case, interestingly I do see some performance 
gain with
your proposed change, though I'm not sure why the loop gets faster with 
a quick
look. So I have created a new Cr #6785335 to keep trace this issue. Will 
consider
put this one into 7 later.

Thanks again!

Sherman


Ulf Zibis wrote:
> Maybe:
>          for (int sl = sp + (sr <= dr ? sr : dr); sp != sl; sp++, dp++)
> is little more faster than:
>          for (int sl = sp + (sr <= dr ? sr : dr); sp < sl; sp++, dp++)
>
> -Ulf
>
>
> Am 15.12.2008 21:56, Ulf Zibis schrieb:
>> Maybe little faster, especially for short strings:
>>
>>       private CoderResult decodeArrayLoop(ByteBuffer src, CharBuffer 
>> dst) {
>>           byte[] sa = src.array();
>>           int sp = src.arrayOffset() + src.position();
>>           int sr = src.remaining();  // faster than ... 
>> src.arrayOffset() + src.limit()
>>
>>           char[] da = dst.array();
>>           int dp = dst.arrayOffset() + dst.position();
>>           int dr = dst.remaining(); // dl is never used
>>
>>           for (int sl = sp + (sr <= dr ? sr : dr); sp < sl; sp++, dp++)
>>               if ((da[dp] = decode(sa[sp])) == UNMAPPABLE_DECODING)
>>                   return 
>> withResult(CoderResult.unmappableForLength(1), src, sp, dst, dp);
>>           return withResult(sr <= dr ? CoderResult.UNDERFLOW : 
>> CoderResult.OVERFLOW, src, sp, dst, dp);
>>       }
>>
>> Regards,
>> Ulf
>>
>