olafurpg
commented
5 years ago @jrudolph Thank you so much for this thorough investigation. I believe the Scalamt codebase is ripe for microoptimizations 👍 The code was written when I was just starting Scala a few years ago and hasn't changed so much since then 😅
I have also investigated several low-hanging opportunities to speed up Scalameta
- delay setting
Tree.parentuntil after parser completes, this seems to speed up parsing ~35% https://github.com/scalameta/scalameta/issues/1130#issuecomment-458899150 - change
Treefrom trait into abstract class, I haven't measured the difference but I suspect we're paying a lot for virtual interface calls.
I personally don't have much time to pursue these ideas but if somebody is interesting in making a contribution I will be happy to provide feedback and review.
kitbellew
Hi @olafurpg,
I spent a bit of time looking into the performance of scalafmt. See the flame-graph below. I found a few things:
VirtualFile.value
That one was a mystery to me first, it amounts to 8% of total time. I guess the problem here is that
Inputis used as a key to many of the Maps. For some reason, scalafmt createsVirtualFiles inScalafmt.formatwhich means that every Map access with theVirtualFileas the key has to hash the complete code again?TreeOps.getOwners
Removing the recursion seems to help and using a java.util.HashMap instead of a mutable.Map builder.
FormatOps.iter
Basically the same as
TreeOps.getOwners.getSplits
That red "Interpreter" frame is
getSplits. It seems to mean that the JIT-compiler gave up on that method completely... It may be as you say:https://github.com/scalameta/scalafmt/blob/8111bb296abf36c8b758a1e43f8ce28b758c03e5/scalafmt-core/shared/src/main/scala/org/scalafmt/internal/Router.scala#L59
Not sure how the pattern match could be restructured to make it easier for the JIT and for performance.
I'll open a PR for ideas about to improve the first three things. That will probably already improve performance somewhat.