Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38503

Re: JDK 9 strings very slow

Show all headers | View raw

 From 2017 source OpenJDK:

Corr.:
for the usual char[] constructor it would, this
time in class StringUTF16 and not StringLatin1:


     public static byte[] compress(char[] val, int off, int len) {
         byte[] ret = new byte[len];
         if (compress(val, off, ret, 0, len) == len) {
             return ret;
         }
         return null;
     }

Same problem, a byte array is allocated and then thrown
away. Does this also happen in StringBuilder.toString()?
Lets check:

     public String toString() {
         // Create a copy, don't share the array
         return isLatin1() ? StringLatin1.newString(value, 0, count)
                           : StringUTF16.newString(value, 0, count);

     }


Lets see what it does, StringUTF16.newString:

        if (String.COMPACT_STRINGS) {
             byte[] buf = compress(val, index, len);
             if (buf != null) {
                 return new String(buf, LATIN1);
             }
         }
         int last = index + len;
         return new String(Arrays.copyOfRange(val,
               index << 1, last << 1), UTF16);

Same nonsense again...

j4n bur53 schrieb:
> So what they wanted to archive, less GC pressure,
> they have traded to more GC pressure when there
> are really no latin1 strings involved?
> 
> I read Closed / Delivered:
> http://openjdk.java.net/jeps/254
> 
> Is this a joke?
> 
> j4n bur53 schrieb:
>> I guess they are kidding:
>>
>>      public static byte[] toBytes(int[] val, int off, int len) {
>>          byte[] ret = new byte[len];
>>          for (int i = 0; i < len; i++) {
>>              int cp = val[off++];
>>              if (!canEncode(cp)) {
>>                  return null;
>>              }
>>              ret[i] = (byte)cp;
>>          }
>>          return ret;
>>      }
>>
>>
>> So the above routine is run for every string,
>> to check whether it can be latin encoded.
>>
>> But the routine does allocate a byte[len],
>> and throws it away when it is not latin.
>>
>> Are there any benchmarks for these strings?
>>
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/share/classes/java/lang/String.java 
>>
> 

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 15:47 +0200
  Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 15:56 +0200
    Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 16:21 +0200
  Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-07-27 10:11 -0400
    Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 16:23 +0200
      Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-07-27 16:25 +0200
  Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-26 09:44 -0700
    Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-08-26 16:36 -0400
      Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-26 23:33 +0200
        Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-08-27 10:31 -0400
          Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-27 19:01 +0200
            Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-27 19:17 +0200
              Re: JDK 9 strings very slow Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-08-27 13:32 -0400
                Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-27 10:49 -0700
                Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-30 18:56 -0700
                Re: JDK 9 strings very slow bursejan@gmail.com - 2018-08-31 00:29 -0700
                Re: JDK 9 strings very slow j4n bur53 <janburse@fastmail.fm> - 2018-08-31 09:56 +0200

csiph-web