Hi Aleksey! On 03/01/2017 03:40 PM, Aleksey Shipilev wrote:
On 03/01/2017 04:34 PM, Claes Redestad wrote:the properties line reader has some relevance to startup, e.g., when reading the java.security file, and as more documentation content has been added to this file it has been made apparent that the handling of comment lines is inefficient due to treating every character after a comment line marker ('#' or '!') as any other character (writes it to an internal buffer etc) when a fast-path consuming the rest of the line would do.Bug: https://bugs.openjdk.java.net/browse/JDK-8176041 Webrev: http://cr.openjdk.java.net/~redestad/8176041/jdk.01The idea looks fine. I think you can go further and unswitch the loop, saving branch in a hot loop, and using byte comparisons (may require some work to do efficient byte-char comparisons): if (inStream != null) { while (inOff < inLimit) { byte b = inByteBuf[inOff++]; if (b == '\n' || b == '\r' || b == '\\') { break; } } } else { while (inOff < inLimit) { c = inCharBuf[inOff++]; if (c == '\n' || c == '\r' || c == '\\') { break; } } }
Sure, with a bit of fix-up this drops another 170k executed bytecodes to read in the java.security file (original: 1882k, now: 980k): http://cr.openjdk.java.net/~redestad/8176041/jdk.02/ It seems javac optimizes byte-char comparisons pretty well in this case since the chars we're comparing against are all in the 0-127 range, so I don't think there's much we can do: 256: getfield #7 // Field inByteBuf:[B 259: aload_0 260: dup 261: getfield #5 // Field inOff:I 264: dup_x1 265: iconst_1 266: iadd 267: putfield #5 // Field inOff:I 270: baload 271: istore 9 273: iload 9 275: bipush 10 <- '\n' 277: if_icmpeq 294 280: iload 9 282: bipush 13 <- '\r' 284: if_icmpeq 294 287: iload 9 289: bipush 92 <- '\\' Thanks! /Claes
Thanks, -Aleksey
