On 2016-01-18 17:20, Claes Redestad wrote:

The ability for URLStreamHandler implementations to override the parseURL method seem to prevent this improvement unless we only do this for a subset of known, well-behaved URLStreamHandlers, which likely defeat the optimization by adding complexity.

Right, the fast path can only be safely used for the non-overrideable handlers (jrt and file), but turns out we can make that work without penalizing other cases:

http://cr.openjdk.java.net/~redestad/8147462/webrev.04/

Relevant micros[1] show that this brings a benefit to file/jrt, even when mixed with slow path URIs, while micros only hitting slow path (newHttpURIToURL, opaqueURIToURL) doesn't regress:

Before:
Benchmark                 Mode  Cnt    Score    Error Units
URIBench.mixedURIToURL    avgt   30  463.748 ± 14.445 ns/op
URIBench.newHttpURIToURL  avgt   30  441.497 ± 20.173 ns/op
URIBench.newURIToURL      avgt   30  227.106 ±  9.055 ns/op
URIBench.opaqueURIToURL   avgt   30  320.904 ± 13.232 ns/op

Patched:
Benchmark                 Mode  Cnt    Score    Error Units
URIBench.mixedURIToURL    avgt   30  441.773 ± 16.530 ns/op
URIBench.newHttpURIToURL  avgt   30  433.946 ± 18.569 ns/op
URIBench.newURIToURL      avgt   30  147.379 ±  6.349 ns/op
URIBench.opaqueURIToURL   avgt   30  316.632 ± 12.940 ns/op

/Claes

[1] http://cr.openjdk.java.net/~redestad/8147462/URIBench.java

Reply via email to