Skip to content

Some results from profiling #1385

@jrudolph

Description

@jrudolph

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 Input is used as a key to many of the Maps. For some reason, scalafmt creates VirtualFiles in Scalafmt.format which means that every Map access with the VirtualFile as 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

Screenshot from 2019-03-14 11-17-25

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:

* NOTE(olafurpg). The pattern match in this file has gotten out of hand. It's

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.

flame-graph

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions