RFR: 8259947: (fs) Optimize UnixPath.encode implementation
Aleksey Shipilev
shade at openjdk.java.net
Tue Jan 19 10:49:51 UTC 2021
On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:
> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>
> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
Changes requested by shade (Reviewer).
test/micro/org/openjdk/bench/java/io/FileToPath.java line 53:
> 51: bh.consume(new File(normalFile).toPath());
> 52: bh.consume(new File(trailingSlash).toPath());
> 53: bh.consume(new File(root).toPath());
No singular test for `new File(root)`, but here it is in the `mix` anyway? What would probably be not comparable.
test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:
> 44: public String root = "/";
> 45: public String trailingSlash = "/test/dir/file/name.txt/";
> 46: public String notNormalizedFile = "/test/dir/file//name.txt";
Can be `private`, I think. As long as those are not `static final`...
-------------
PR: https://git.openjdk.java.net/jdk/pull/2135
More information about the core-libs-dev
mailing list