Grab bag of compiler optimizations #3445
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Avoid the Applied extractor altogether, as that eagerly creates `argss` which we don't need and which is quite expensive.
It's called rather frequently. Tree#symbol is a megamorphic call, which featured in profiles.
Anything we can do to make erasure faster.
isPossibleRefinement reported as 1% of my profile, about half of that was reported from the `EraserTyper`. This commit restricts `checkMethodStructuralCompatible` to the typer phase, and also moves in the feature warning for implicits which was nearby. I've also made a minor optimization to `overriddenSymbol` by avoiding computing the method schema repeatedly.
| @@ -861,7 +861,7 @@ private[internal] trait TypeMaps { | |||
| class InstantiateDependentMap(params: List[Symbol], actuals0: List[Type]) extends TypeMap with KeepOnlyTypeConstraints { | |||
| private val actuals = actuals0.toIndexedSeq | |||
| private val existentials = new Array[Symbol](actuals.size) | |||
| def existentialsNeeded: List[Symbol] = existentials.filter(_ ne null).toList | |||
| def existentialsNeeded: List[Symbol] = existentials.iterator.filter(_ ne null).toList | |||
There was a problem hiding this comment.
Even faster (typically) is
{ val lb = List.newBuilder[Symbol]; existentials.foreach(x => if (x ne null) lb += x); lb.result }
and faster still is
{ val lb = List.newBuilder[Symbol];
var i = 0
while (i< existentials.length) {
val x = existentials(i)
if (x ne null) b += x
i += 1
}
lb.result
}
How big of a bottleneck is this? Is it worth going that low-level?
There was a problem hiding this comment.
This patch was enough to take this off my profiling radar. It was a bottleneck, but only in one of the dozens of bottles I was looking at. :)
Creating a throwaway Array (generically) was the drastically expensive thing I wanted to avoid.
|
From a performance perspective, LGTM aside from the issue I highlighted above. |
Avoid creating a throwaway array in existentialsNeeded.
Shadowing is rarer than implausbility; this seems to be the most efficient way to order these filters.
Use `hasAttachment` rather than `getAttachment.exists`
Cache it, rather than recreating it for each candidate overriden method we encounter. We can't do this eagerly as we trip a cycle in neg/t5093.scala.
|
Just pushed a fix for the bad apple, "Optimize use of methodTypeSchema", and moved it do the end of the commit list. Other commits are unchanged. |
ghost
assigned 
|
PLS SYNCH |
|
(kitty-note-to-self: ignore 33877495) |
gkossakowski
added a commit
that referenced
this pull request
Feb 2, 2014
Grab bag of compiler optimizations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@gkossakowski This work comes from my branch that we
went through in Lausaunne a few months back.
Sorry I was so slow to submit this as PRs. I had hoped
to find more time to robustly benchmark, but you know
how it goes...
When I tried, your benchmark tool showed the usual
problems of saying anything conclusive about individual
commits, but the trend over the entire series unambigious.
The entire series showed ~30% delta for FSC-style compilation,
~20% for SBT-style (new Global instance each compilation batch.)
I'm trying to submit what I consider to be uncontroversial
changes in groups. If a particular change requires deeper
review, I'll submit it individually.
/cc @Ichoran