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