Skip to content

Optimize megaphase #9597

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 4 commits into from
Aug 21, 2020
Merged

Optimize megaphase #9597

merged 4 commits into from
Aug 21, 2020

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Aug 19, 2020

No description provided.

odersky added 3 commits August 19, 2020 18:51
@odersky
Optimize transformTrees
b58efbc 
Avoid the closure creation. Downside: the function is no longer
tail recursive. But this hopefully matters less, since lists of
trees are rarely very long. If they do get longer to be dangerous
for stack overflows we fall back to a more conservative implementation.
@odersky
Optimize MegaPhase.transformStats
60a4758
@odersky
Use inline constant
0315e27
@odersky
Copy link
Contributor Author

odersky commented Aug 19, 2020

test performance please

@dottybot
Copy link
Member

performance test scheduled: 11 job(s) in queue, 1 running.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9597/ to see the changes.

Benchmarks is based on merging with master (c5e1f0c)

@liufengyun
Copy link
Contributor

test performance please

@dottybot
Copy link
Member

performance test scheduled: 8 job(s) in queue, 1 running.

@odersky
Copy link
Contributor Author

odersky commented Aug 20, 2020

test performance please

@dottybot
Copy link
Member

performance test scheduled: 8 job(s) in queue, 1 running.

liufengyun
liufengyun approved these changes Aug 20, 2020
View reviewed changes
Copy link
Contributor

@liufengyun liufengyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, let's see which recursive number is better.

BTW, we can run benchmarking for multiple commits like test performance please: dd9dbf4 0315e27, which results in one point for each commit.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9597/ to see the changes.

Benchmarks is based on merging with master (80d9dcc)

@odersky
Copy link
Contributor Author

odersky commented Aug 20, 2020

It seems the lower number is dramatically better! So, deep stacks seem to be a performance bottleneck. I am going to test without the optimization altogether, to get another comparison.

@odersky
Copy link
Contributor Author

odersky commented Aug 20, 2020

test performance please

@dottybot
Copy link
Member

performance test scheduled: 11 job(s) in queue, 1 running.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9597/ to see the changes.

Benchmarks is based on merging with master (188b99c)

@odersky
Copy link
Contributor Author

odersky commented Aug 20, 2020 •
edited
Loading

So recursing 1000 levels before going into the fall-back is clearly worse than doing nothing, but recursing 10 levels is clearly better. Reverting to that state.

@odersky odersky force-pushed the optimize-megaphase branch from c504967 to dd9dbf4 Compare August 20, 2020 21:45
@odersky odersky merged commit 7815b6a into scala:master Aug 21, 2020
@odersky odersky deleted the optimize-megaphase branch August 21, 2020 06:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@liufengyun liufengyun liufengyun approved these changes

Assignees

@liufengyun liufengyun

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@odersky @dottybot @liufengyun