RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

Claes Redestad claes.redestad at oracle.com
Wed Jan 27 17:24:22 UTC 2016


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


More information about the net-dev mailing list