-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Various performance optimizations / experiments [ci: last-only] #5785
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
Conversation
Any types that needed to be specialized to support callsites in the current run would have already been info transformed during the specalization tree transform of those call sites. The backend requires further type information, e.g, to know about inner/enclosing class relationships. This involves calls to `sym.info` for classes on the classpath that haven't yet been info transformed. During that process, all base classes of such types are also info transformed. The specialization info transformer for classes then looks at the members of the classes to add specialialized variants. This is undesirable on grounds of performance and the risk of encountering stub symbols (references to types absent from the current compilation classpath) which can manifest as compiler crashes.
Avoid use of BoxesRuntime equals in favour of direct use of Object#equals.
This reverts commit 30a440a.
case ArrayBType(component) => "[" + component | ||
case MethodBType(args, res) => "(" + args.mkString + ")" + res | ||
final override def toString: String = { | ||
val builder = new StringBuilder(64) |
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.
You can save an extra allocations here by using the java StringBuilder directly.
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.
Ignore me I think you did the change in another commit.
I haven't managed to get the benchmark server producing stable enough results, so I performed benchmarking locally. Results Hot compilation of The benefits will vary somewhat depending on the codebase being compiled, e.g. @rorygraves reports a 22% improvement for compiling There are a few commits that appear to be clear winners, and then many that are hard to reason about in isolation as the individual performance changes are around the same level as the noise in the benchmark. I'm going to close this pull request an submit smaller PRs, starting with changes that have the best cost/benefit ratio (easy to review patches / big performance improvement). |
Puship WIP here to facilitate benchmarking.