-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed improvements #33
Conversation
The plexus DirectoryScanner usually access the file system multiple times for each file, so cache all attributes
@@ -40,7 +40,7 @@ public static PlexusIoResource createProxy( @Nonnull PlexusIoResource target, Ob | |||
interfaces.add( ResourceAttributeSupplier.class ); | |||
|
|||
return (PlexusIoResource) Proxy.newProxyInstance( PlexusIoResource.class.getClassLoader(), | |||
interfaces.toArray( new Class[interfaces.size()] ), | |||
interfaces.toArray( new Class[0] ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what it is improving?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The long answer is here, the short one is that interfaces.toArray( new Class[0] )
is faster than interfaces.toArray( new Class[interfaces.size()] )
mainly because the JVM does not need to zero the array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks that's interesting read. But it's from 2016 and the conclusion says Future VM optimizations may close this performance gap for toArray(new T[size])
so it could be interesting to have similar benchmark now almost 5 years later :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the bench results on a recent JDK 14 JVM. It does not seem the results of the article have changed much, though the difference is quite small...
Benchmark (size) (type) Mode Cnt Score Error Units
ToArrayBench.simple 0 arraylist avgt 3 5.854 ± 1.322 ns/op
ToArrayBench.simple 0 hashset avgt 3 5.641 ± 0.389 ns/op
ToArrayBench.simple 1 arraylist avgt 3 8.003 ± 0.972 ns/op
ToArrayBench.simple 1 hashset avgt 3 15.671 ± 3.531 ns/op
ToArrayBench.simple 10 arraylist avgt 3 8.805 ± 8.413 ns/op
ToArrayBench.simple 10 hashset avgt 3 28.156 ± 2.709 ns/op
ToArrayBench.simple 100 arraylist avgt 3 28.388 ± 2.799 ns/op
ToArrayBench.simple 100 hashset avgt 3 285.236 ± 56.555 ns/op
ToArrayBench.simple 1000 arraylist avgt 3 288.888 ± 83.145 ns/op
ToArrayBench.simple 1000 hashset avgt 3 2340.670 ± 651.868 ns/op
ToArrayBench.sized 0 arraylist avgt 3 6.343 ± 1.680 ns/op
ToArrayBench.sized 0 hashset avgt 3 5.568 ± 0.957 ns/op
ToArrayBench.sized 1 arraylist avgt 3 11.708 ± 0.874 ns/op
ToArrayBench.sized 1 hashset avgt 3 21.645 ± 10.234 ns/op
ToArrayBench.sized 10 arraylist avgt 3 20.294 ± 0.902 ns/op
ToArrayBench.sized 10 hashset avgt 3 45.420 ± 11.422 ns/op
ToArrayBench.sized 100 arraylist avgt 3 129.215 ± 27.252 ns/op
ToArrayBench.sized 100 hashset avgt 3 472.538 ± 75.969 ns/op
ToArrayBench.sized 1000 arraylist avgt 3 1164.126 ± 207.183 ns/op
ToArrayBench.sized 1000 hashset avgt 3 4204.794 ± 407.450 ns/op
ToArrayBench.zero 0 arraylist avgt 3 4.554 ± 0.187 ns/op
ToArrayBench.zero 0 hashset avgt 3 4.377 ± 2.012 ns/op
ToArrayBench.zero 1 arraylist avgt 3 10.969 ± 1.892 ns/op
ToArrayBench.zero 1 hashset avgt 3 21.890 ± 1.103 ns/op
ToArrayBench.zero 10 arraylist avgt 3 18.158 ± 1.774 ns/op
ToArrayBench.zero 10 hashset avgt 3 34.278 ± 4.633 ns/op
ToArrayBench.zero 100 arraylist avgt 3 113.737 ± 31.070 ns/op
ToArrayBench.zero 100 hashset avgt 3 420.547 ± 104.867 ns/op
ToArrayBench.zero 1000 arraylist avgt 3 994.804 ± 400.316 ns/op
ToArrayBench.zero 1000 hashset avgt 3 3975.771 ± 658.523 ns/op
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@olamy that said, if you don't like the change, I can remove it, it won't impact much on the overall performances one way or another.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh no I'm fine with that. I never read this blog post and surprised to have to change a pattern I'm using for so many years now 🤣
This reverts commit bf86860.
This reverts commit bf86860.
No description provided.