Hi there. This is a super useful tool but unfortunately I appear to be experiencing some difficulties with it at the moment.

I've got -Vstatistics set and info associated with that flag is coming through as expected. Importantly on some of our modules we are getting expected results (deterministically), so I think the plugin must be set up correctly, but most are having the issue below, where the flamegraph file is empty and the following macro / implicit fields are all empty.

There isn't an obvious difference between the ones that are working and the ones that aren't. It's worth noting that many of these modules spend up to 5 minutes in implicit resolution, so perhaps it's overflowing something. Many fail that don't have this issue though.

scalacProfiling version: 1.1.0-RC2
Scala Version: 2.13.12
sbt version: 1.9.6

Apologies if this is not much to go on, happy to try and provide any other info I can. Perhaps scalac has some verbose mode I could turn on?

[info] Writing graph to [...]/implicit-searches-1714143535655.flamegraph
[info] Writing graph to [...]/implicit-searches-global.flamegraph
[info] Writing graph to [...]/macros-1714143535655.flamegraph
[info] Macro data per call-site:
[info] Map()
[info] Macro data per file:
[info] HashMap()
[info] Macro data in total:
[info] MacroInfo(expandedMacros = 0, expandedNodes = 0, expansionNanos = 0L)
[info] Macro repeated expansions:
[info] Map()
[info] Macro expansions by type:
[info] LinkedHashMap()
[info] Implicit searches by position:
[info] LinkedHashMap()
[info] Implicit searches by type:
[info] LinkedHashMap()

The compiler plugin doesn't generate useful data if you don't add the -Ystatistics.
It should fail the compilation or, at least, print a warning to inform the user to add the option.

I'm going to go through the application for DocSearch by Algolia https://docsearch.algolia.com/apply/

adding the sbt plugin to my project fails to resolve. is it published yet? do I need to add a customer resolver?
getting this error

I have enabled compiler option -P:scalac-profiling:no-profiledb, but on the first SBT startup, I get the following logs:

Writing graph to /Users/foobar/baz-project/project/target/config-classes/META-INF/profiledb/graphs/implicit-searches-1699025774362.flamegraph
Creating global statistics information at /Users/foobar/baz-project/project/target/config-classes/META-INF/profiledb/global.profiledb.
Writing graph to /Users/foobar/baz-project/project/target/config-classes/META-INF/profiledb/graphs/implicit-searches-1699025774514.flamegraph
Creating global statistics information at /Users/foobar/baz-project/project/target/config-classes/META-INF/profiledb/global.profiled

On the actual run of the scalac-profiling, the mentioned files don't create and fill in.
What's interesting, on the subsequent startups of the SBT, this info isn't being printed.

expandedNodes and expansionNanos are always 0 in the output generated when the show-profiles flag is enabled.

Example code:

import io.circe.generic.semiauto._
import io.circe.generic.auto._
object Main {
  case class T(f1: Either[List[List[List[Int]]],Option[String]])
  def main(args: Array[String]): Unit = deriveCodec[T]
}

Output:

[info] time spent in macroExpand     : 180 spans, ()344.558ms (88.6%)
[info] Macro data per call-site:
[info] Map(
[info]   NoPosition -> MacroInfo(expandedMacros = 6, expandedNodes = 0, expansionNanos = 0L),
[info]   source-testproj/src/main/scala/Main.scala,line-7,offset=198 -> MacroInfo(
[info]     expandedMacros = 58,
[info]     expandedNodes = 0,
[info]     expansionNanos = 0L
[info]   )
[info] )
[info] Macro data per file:
[info] HashMap(
[info]   Main.scala -> MacroInfo(expandedMacros = 58, expandedNodes = 0, expansionNanos = 0L),
[info]   <no source file> -> MacroInfo(expandedMacros = 6, expandedNodes = 0, expansionNanos = 0L)
[info] )
[info] Macro data in total:
[info] MacroInfo(expandedMacros = 64, expandedNodes = 0, expansionNanos = 0L)

This is occurring in both 2.12 and 2.13 for me.

I haven't actually tried running it yet, but https://github.com/slamdata/quasar has more and more serious compilation time issues than any project I've ever worked on (and I've worked on shapeless, emm, and some other doozies). It would be an excellent candidate for seeing exciting things, especially related to type inference, complex higher-kinded types, and complex implicit resolution (though some of this has been tamped down since we switched out scalaz.Coproduct for Iota).

I didn't know scalac-profile had a documentation website until I saw the docs directory and searched the docs on google.
It should have the link in the README and in the Github repository metadata so users can easily find it.

I'll make this change in a future release.

I was trying out this guide to profile a project.

I added the following in sbt

  "-Ycache-plugin-class-loader:last-modified",
  "-Xplugin:$PATH_TO_PLUGIN_JAR",
  "-P:scalac-profiling:no-profiledb",
  "-P:scalac-profiling:show-profiles",
  "-P:scalac-profiling:sourceroot:$BLOOP_CODEBASE_DIRECTORY"

When I do console from sbt shell, I get a NPE here
as _.file returns null

That's strange because when building the website locally, everything is fine, and SVGs are clickable as expected 🤔

scala-steward-implicit-searches-flamegraph.svg:125 Uncaught TypeError: Cannot read properties of undefined (reading 'firstChild')
    at g_to_text (scala-steward-implicit-searches-flamegraph.svg:125:36)
    at scala-steward-implicit-searches-flamegraph.svg:59:50
scala-steward-implicit-searches-flamegraph.svg:65 Uncaught TypeError: Cannot set properties of undefined (setting 'nodeValue')
    at scala-steward-implicit-searches-flamegraph.svg:65:33

Scala 2.13 is out! However it seems like this plugin only builds for 2.12 currently

I'd like to update FlameGraph. I've applied several patches to the latest FlameGraph, just like Jorge made 5 years ago on his fork, and all appears to be good. If you can fork the FlameGraph into the Scala Center Github organization, I will do the rest of the stuff. @sjrd wdyt?

Currently scalac-profiling is able to generate a Flamegraph per compilation unit (sbt module).
In a big project is hard to see what is really taking most of the time to compile.
Also, you need to open and visualize tens of flamegraphs, which is overwhelming.

The Usage section says to do --color=scala-compilation when you run Flamegraph, but that makes it all black and it's hard to distinguish the flamegraph segments:

If I remove that flag, we get nicer colors:

--color= doesn't seem to be a valid flag in the version of Flamegraph I used, so maybe it used to be?

Either way, I'm proposing removing that line from the docs.

Now that we have Scala 2.13 support, it's natural to wonder about Scala 3.

Creating the Scala 2 version involved adding some hooks to the old compiler, so the new compiler might need new hooks, too?

Note that Scala 3 has -Vprofile, but it's only somewhat related to what this repo does. ("Show metrics about sources and internal representations of the most complex methods", its docstring says.)

Originally, scalac-profiling was designed in terms of SBT, and it relies on SBT's target structure when assembling output flamegraphs. As @lolgab proposed in #50, by tweaking the approach for dealing with output directories, we may open the door for other build tools like mill.

Versions: SBT 1.9.6, Scala 2.13.12, scalac-profiling 1.1.0-RC2
I've tried adding scalac-profiling to our project, following the documentation, but it prints this in the log either once, or many times (I presume once per project):

`scalac-profiling` compiler plugin requires the option `-Ystatistics` to be enabled

First, it's weird that it's mentioning -Ystatistics and not -Vstatistics, as I'm running Scala 2.13. Second, specifying either one makes the compiler print stats, as expected, but the plugin somehow doesn't detect that and still prints this error and doesn't generate any output.

At the moment, scalac-profiling depends on the fork of Flamegraph, which is seemingly abandoned and hasn't been updated for 5+ years. It'd be beneficial if someone could create a fresh fork based in the Center organization. Who can assist with that? cc @SethTisue @sjrd

Looking at the flamegraph, it's hard to understand where the code is coming from. You need to guess.
It would be nice to have something that points to the definition of the function taking implicit parameters, so I can then check its usages or ways to improve it.

Several projects within the Center already use it, and it seems quite good.

I think it would be interesting to check how many symbols are completed overall. This can help us pinpoint problems with excessive completion, especifically for cold and first compilations.

@retronym Do you think this would be useful?

It's not good for a 2018 blog post to also serve as the documentation. We should keep it in-repo so we can update it.

We could add a note to the top of the old post, redirecting readers to the current documentation. (This is what we did, for example, with https://www.lightbend.com/blog/scala-inliner-optimizer which eventually turned into the more permanent https://docs.scala-lang.org/overviews/compiler-options/optimizer.html.)

The crux

It turns out, that the current show-profiles option generates massive useful debug info and logs it just into the output. That makes exploring data pretty tough. To tackle this, I propose introducing a new compiler plugin option export-profiles, that should prepare the same data in a human-readable format and write it to some external file.

Implementation details

As things stand in 1.1.0-RC2, show-profiles generates the following sets of data:

• Macro data per call-site
• Macro data per file
• Macro data in total
• Macro repeated expansions
• Macro expansions by type
• Implicit searches by position

We need to think about the file format to make data convenient for further exploration. At the moment, I'm thinking about defining the .md file consisting of tables for the mentioned data sets. But still not sure. Any ideas?

cc @lolgab @SethTisue

The guide has flame graphs whose unit is "ns". This unit is wrong, I meant microseconds. Fixing this would require regenerating all the flame graphs in the guide.

Reported by @fommil after a successful use of the plugin!

@sjrd has said on Discord that @danicheg would already qualify based on his record of contribution

For example, supporting zipkin so that the flame graph data can be connected with bloop's zipkin auto-tracing support.