RFR: 8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser (original) (raw)
Peter Levart peter.levart at gmail.com
Wed Nov 30 11:36:01 UTC 2016
- Previous message: RFR: 8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser
- Next message: RFR: 8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Claes, Andrej,
On 11/29/2016 11:53 PM, Claes Redestad wrote:
http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424SignatureParser.performance/webrev.02/
What do you think of this one? Fair point. I think this is easier to follow and should do the trick just as nicely. What you have here is fine, but in this day and age of compact strings I wonder if return mar.replace('/', '.') might have both a readability and a slight performance edge (assuming signatures are almost always ASCII).
Good idea. It simplifies code and improves performance.
On 11/30/2016 08:38 AM, Andrej Golovnin wrote:
Hi Peter,
I know it is matter of taste, but don't you think this: 269 for (char c = current(); 270 c != ';' && c != '.' && c != '/' && c != '[' && 271 c != ':' && c != '>' && c != '<' && 272 !Character.isWhitespace(c); 273 c = current()) 274 { is easier to read than the long or-condition which is then negated?
Indeed it is. Another good idea, thanks.
Here's a webrev incorporating both suggestions. All 73 java/jang/reflect jtreg tests are passing...
http://cr.openjdk.java.net/~plevart/jdk9-dev/8035424_SignatureParser.performance/webrev.03/
Regards, Peter
- Previous message: RFR: 8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser
- Next message: RFR: 8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]