Skip to content
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

Apply Optimize Java 8 Stream refactoring #1

Closed
wants to merge 1 commit into from

Conversation

khatchad
Copy link

Apply Optimize Java 8 Streams Refactoring

Description

This is a semantics-preserving automated refactoring that attempts to optimize code using Java 8 streams when it is safe and possibly advantageous to do so. It may make certain streams parallel, others sequential, and unorder streams where necessarily. The tool does not add new functionality; it only rearranges existing code in an effort to increase its performance. Your program's results should be the same before and after the refactoring.

Details

  • We are evaluating a research prototype automated refactoring Eclipse plug-in called Optimize Java 8 Streams Refactoring. We have applied the tool to your project in the hopes of receiving feedback.
  • The approach is very conservative. That may mean that not all changes that can be made were made.
  • The source code should be semantically equivalent to the original.
  • The tool does not assess overhead vs. the amount of data processed; it only performs the refactoring when it is safe and possibly advantageous to do so. However, we ran several performance tests on the refactored code (see below).

Performance Evaluation

We did not find dedicated performance tests in your project (please let us know if we missed it). But, we did evaluate our tool on other projects (see iluwatar/java-design-patterns#786 (comment) and numenta/htm.java#539 (comment)). We have found an average speedup of ~3.25 as a result of our refactoring across all of our tests thus far.

Feedback

Thank you for your help in this evaluation! Any feedback you can provide would be very helpful. In particular, we are interested if each of the proposed changes are helpful or not.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 71.257% when pulling 8dd815c on ponder-lab:develop into a7fc04b on RutledgePaulV:develop.

@RutledgePaulV
Copy link
Owner

This change makes no sense for my project given that the stream is always of a single element. Furthermore, I don't think just making streams parallel is a suitable optimization without consideration of the program context in which it is running since it shares the JVM global fork join pool.

@khatchad
Copy link
Author

Thank you for the feedback, @RutledgePaulV!

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.

None yet

3 participants