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

[Ulf Zibis]

Wow, very fast, your answer  :-)

Maybe you can also examine this:

        private CoderResult decodeArrayLoop(ByteBuffer src, CharBuffer 
dst) {
            byte[] sa = src.array();
            int sp = src.arrayOffset() + src.position();
            int sr = src.remaining();

            char[] da = dst.array();
            int dp = dst.arrayOffset() + dst.position();
            int dr = dst.remaining();

            int sl;
            CoderResult cr;
            if (sr <= dr) {
                sl = sp + sr;
                cr = CoderResult.UNDERFLOW;
            } else {
                sl = sp + dr;
                cr = CoderResult.OVERFLOW;
            }

            for (; sp != sl; sp++, dp++) {
                char c = decode(sa[sp]);
                if (c == UNMAPPABLE_DECODING)
                    return 
withResult(CoderResult.unmappableForLength(1), src, sp, dst, dp);
                da[dp] = c;
            }
            return withResult(cr, src, sp, dst, dp);
        }


... but I think, my first version is more elegant. ;-)

-Ulf



Am 15.12.2008 23:19, Xueming Shen schrieb:
>
> 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
>