On 27 Jan 2016, at 17:24, Claes Redestad <claes.redes...@oracle.com> wrote:
> > 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/ This looks fine Claes. Maybe just a comment on the fact that character based comparison is being used for perf reasons. In an older version of the webrev, there was an updated to an existing test, test/java/net/URI/URItoURLTest.java. I assume this was just mistakenly omitted from the latest version? -Chris. > 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
