Skip to content

offloading file copy work to operating system allows potential speedup #12

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

Merged
merged 1 commit into from
Jun 14, 2016

Conversation

mkarg
Copy link
Collaborator

@mkarg mkarg commented May 24, 2016

Since Plexus Utils enforces Java 7 it is safe to invoke NIO operations introduced by JRE 7. Among those operations are methods for potentially offloading work to the operating system. Theoretically this should be (much) faster on modern JREs than pumping bytes up and down the JVM just to get them from one file into another. Even without any actual performance gain it makes sense to get rid of custom code in favor of JRE code, as it improves class loading speed and reduces memory and
on-disk footprint, while cutting down number of potential bugs at the same time.

@krosenvold
Copy link
Member

P-u is jdk 1.6

@mkarg
Copy link
Collaborator Author

mkarg commented Jun 12, 2016

Maven didn't complain. Possibly a missing constraint in the POM?
Any plans to support JDK 7 some day, so APIs like the one I used is "safe"?

@khmarbaise
Copy link
Member

Plexus utils are not only used in Maven itself (where it wouldn't be problem), but they are used in many plugins as well which are JDK 6...

@mkarg
Copy link
Collaborator Author

mkarg commented Jun 12, 2016

Would it be OK if I check the JRE level at runtime and invoke either the existing code or the new code?

@krosenvold
Copy link
Member

Yes, that'd be fine. There is probably a "isJdk7" method somewhere in there already.

Since Plexus Utils enforces Java 7 it is safe to invoke NIO operations
introduced by JRE 7. Among those operations are methods for potentially
offloading work to the operating system. Theoretically this should be
(much) faster on modern JREs than pumping bytes up and down the JVM just
to get them from one file into another. Even without any actual
performance gain it makes sense to get rid of custom code in favor of
JRE code, as it improves class loading speed and reduces memory and
on-disk footprint, while cutting down number of potential bugs at the
same time.
@mkarg
Copy link
Collaborator Author

mkarg commented Jun 13, 2016

Done. :-)

@olamy olamy merged commit 49a1662 into codehaus-plexus:master Jun 14, 2016
@mkarg mkarg deleted the offloading branch June 14, 2016 20:56
@rfscholte rfscholte added this to the 3.1.0 milestone May 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants