Merge pull request #910 from ashawley/fix-scalac-profiling-post

Fix scalac-profiling post

Author: jvican

blog/_posts/2018-06-04-scalac-profiling.md

@@ -2,7 +2,7 @@
 layout: blog-detail
 post-type: blog
 by: Jorge Vicente Cantero
-title: "Speeding Up Compilation Time with `scalac-profiling`"
+title: "Speeding Up Compilation Time with scalac-profiling"
 ---
 
 In this blog article, I’d like to introduce you to a new tool that we’ve
@@ -11,10 +11,10 @@ better understand what is slowing down compilation in your project.
 
 It turns out that the use of Scala's implicits as well as macros can greatly
 increase compilation times, depending on how they are used and how your
-codebase is organized. Codebases that make use of libraries like Shapeless,
+codebase is organized. Codebases that make use of libraries like [Shapeless],
 or which rely on typeclass derivation, may be particularly prone to these
-slow-downs. (As of Scala 2.12, typeclass derivation is based on
-implicitly-triggered macro expansions.)
+slow-downs. As of Scala 2.12, typeclass derivation is based on
+implicitly-triggered macro expansions.
 
 The goal of this blog post is to help you understand when these things are
 happening in your code, so you can remove code that triggers unnecessary
@@ -82,7 +82,7 @@ it should compile in ~4 seconds.
 `frontend` depends on
 [`case-app`](https://github.com/alexarchambault/case-app/), a command-line
 parsing library for Scala that uses
-[Shapeless](https://github.com/milessabin/shapeless). This library is
+[Shapeless]. This library is
 excellent, but slows our compilation down to 30 seconds.
 
 Waiting 30 seconds for a change to take effect (even under incremental
@@ -194,9 +194,9 @@ Add the compiler flag to the field `options` inside the
 automatically pick up your changes and add the compiler option without the
 need of a `reload`.
 
-(If you use sbt, add `scalacOptions in Compile += "-Ystatistics"` to your
+If you use sbt, add `scalacOptions in Compile += "-Ystatistics"` to your
 project settings. If you want to profile tests scope it to `Test` instead of
-`Compile`.)
+`Compile`.
 
 Run `bloop compile frontend -w --reporter scalac` (we use the default scalac
 reporter for clarity) and have a look at the data. The output of the
@@ -270,7 +270,7 @@ following counters:
 ```
 
 The Scala compiler creates almost two million class symbols (!) and
-typechecks 134734 identifiers, almost the double of selections and half of
+typechecks 134734 identifiers, almost double the selections and half of the
 applications. Those are pretty high values. That begs the question: why are
 we creating so many classes?
 
@@ -290,7 +290,7 @@ sequence of types -- also called finding "least upper bound" among some
 types). Eugene Yokota explains it well [in this well-aged blog
 post](http://eed3si9n.com/stricter-scala-with-ynolub).
 
-`time spent in findmember` and it's sister `time spent in findmembers` should
+`time spent in findmember` and its sister `time spent in findmembers` should
 be up in the profiles whenever you have deep class hierarchies and lots of
 overridden methods.
 
@@ -300,9 +300,9 @@ dependent types, type projections or abstract types in a more general way.
 In the case of `frontend`, the durations of all these operations are
 reasonable, which hints us that the inefficiency is elsewhere.
 
-(For most of the cases, these timers are unlikely to be high when typechecking
+For most of the cases, these timers are unlikely to be high when typechecking
 your program. If they are, try to figure out why and file a ticket in
-`scala/bug` so that either I or the Scala team can look into it.)
+[Scala compiler's issue tracker](https://github.com/scala/bug/) so that either I or the Scala team can look into it.
 
 ### The troublemaker
 
@@ -561,7 +561,7 @@ typeclass derivation. When used in that context, it is common that the compiler
 repeats the materialization of implicit instances. This is the main source of
 inefficiencies.
 
-Travis Brown explains these inefficiences well in a more high-level manner in
+Travis Brown explains these inefficiencies well in a more high-level manner in
 [this talk about Generic
 Derivation](https://meta.plasm.us/slides/scalaworld/#65) at Scalaworld.
 
@@ -586,7 +586,7 @@ implicitly[Encoder[Foo]]
 implicitly[Encoder[Bar]]
 ```
 
-For example, the code above illustrates how an hypothetic `Encoder` typeclass
+For example, the code above illustrates how a hypothetical `Encoder` typeclass
 would need to materialize `List[String]` **twice** since its type appears in
 both definitions. The second call cannot detect that the first one
 synthesizes `Encoder[List[String]]` because for all purposes there isn't an
@@ -596,8 +596,8 @@ The same happens in nested implicit searches and it worsens as more and more
 functional dependencies generated by macros and nested types are used and
 required in every step of the inductive process.
 
-Remember that `frontend` was expanding 44500 macros and how intense was
-typechecking? Well, now we have a faint idea why.
+Remember that `frontend` was expanding 44500 macros and how intense
+typechecking was? Well, now we have a faint idea why.
 
 
 ## The quest for optimization
@@ -706,7 +706,7 @@ turn handy whenever you research on your own. Check the rest of the supported
 compiler plugin flags [in the code](https://github.com/scalacenter/scalac-profiling/blob/master/plugin/src/main/scala/ch/epfl/scala/ProfilingPlugin.scala#L33-L40).
 
 After this short intro, let's delve into the data. The first thing that
-strucks me is how similar all the towers of implicits look (both in shape and
+struck me is how similar all the towers of implicits look (both in shape and
 duration). If we hover over all the chunks, the repetition will be obvious;
 most bite-sized chunks materialize either `Parser[CommonOptions]` or
 `Parser[CliOptions]`, depending at the height of the implicit branch we look
@@ -753,7 +753,7 @@ Great! Well, let's check the compile time and flamegraphs now.
 The compile time is 2.5x faster. Not bad for a two line change. The duration
 of implicit search accounts for 13 seconds, roughly ~95% of typer.
 
-The flamegraph has slim down and doesn't contain the successful implicit
+The flamegraph has slimmed down and doesn't contain the successful implicit
 searches for `Parser[CommonOptions]` and `Parser[CliOptions]`. However, there
 seems to be quite a few of failed implicit searches that trigger unnecessary
 macro expansions that are afterwards discarded because their type doesn't
@@ -771,16 +771,16 @@ when finding an implicit for `HListParser` (which takes type parameters
 [inferred from its other functional
 dependencies](https://github.com/alexarchambault/case-app/blob/v1.2.0/core/shared/src/main/scala/caseapp/core/Parser.scala#L77-L84)).
 
-Let's further debug this with `-Xlog-implicits` (by adding it to the scalac
-options of the bloop configuration file).
+Let's further debug this by adding `-Xlog-implicits` to the scalac
+options of the bloop configuration file.
 
-(This is a good moment to try to minimize the problem. `-Xlog-implicits` will
+This is a good moment to try to minimize the problem. `-Xlog-implicits` will
 log a lot of failed searches and we want to be able to see through the noise.
 I did minimise the issue
 [here](https://github.com/scalacenter/scalac-profiling/pull/23/commits/dbcb8d480e9b402899d21620055bc555b2841382).
-Doing `implicitly[Parser[CliOptions]]` also reproduces it.)
+Doing `implicitly[Parser[CliOptions]]` also reproduces it.
 
-Among all the logs, this is the one that calls most my attention.
+Among all the logs, this is the one that attracts my attention the most.
 
 ```
 /data/rw/code/scala/loop/frontend/src/main/scala/bloop/cli/CliParsers.scala:48:37: shapeless.this.Generic.materialize is not a valid implicit value for shapeless.Generic.Aux[bloop.cli.CommonOptions,V] because:
@@ -818,7 +818,7 @@ and
 The problem of incorrect instantiated type arguments we saw before seems
 specific to the way the compiler carries out the implicit search. Fixing it
 requires most likely changes to the implicit search algorithm, as [a similar
-scala/bug did](https://github.com/scala/bug/issues/10528). I tried porting
+Scala compiler issue](https://github.com/scala/bug/issues/10528) did. I tried porting
 these changes to 2.12.x and use `-Xsource:2.13` but the failed macro
 expansions didn't go away.
 
@@ -943,7 +943,7 @@ and the returned refinement type from the macro was `Option[String] ::
 this.P`.
 
 We can try to debug and expand all type parameters, see what we get and
-continue the exploration from there. But whenever we find such a misterious
+continue the exploration from there. But whenever we find such a mysterious
 open-ended error, it's difficult to pinpoint what the real problem and fix
 should be.
 
@@ -1006,12 +1006,12 @@ experienced with the codebase have a look at it. If we're lucky, someone will
 fix this issue upstream soon and we'll benefit from this speed up when we
 upgrade.
 
-(After discussing this issue with [Miles](https://github.com/milessabin/) we
+After discussing this issue with the author of Shapeless, [Miles Sabin](https://github.com/milessabin/), we
 both agree the strict/lazy macro is not handling refinement types correctly
 and that this performance penalty is a bug. This bug will most likely be fixed
 in a future version of Shapeless after 2.3.3 for all its users. Some of these
 performance implications will be gone with Scala 2.13, that adds by-name
-implicits to the compiler.)
+implicits to the compiler.
 
 #### Deduplicating more expansions
 
@@ -1243,8 +1243,8 @@ Done compiling.
 It is safe to say it out loud now: we have reduced compilation time from 32.5
 seconds to 4 seconds. That's an **8x reduction in our compile time**.
 
-A great result taking into account that we've only modified around 30 lines
-of code.
+A great result taking into account that we've only [modified around 30 lines
+of code in Bloop](https://github.com/scalacenter/bloop/pull/509).
 
 ## Conclusion
 
@@ -1294,6 +1294,8 @@ knowledge to invalidate caching depending on the kind of macro and call-site.
 There's a bright future ahead of us and we are working hard to get there.
 
 In the meanwhile, this blog post aims to provide all the possible data to
-alleaviate the compile times of users that leverage automatic typeclass
+alleviate the compile times of users that leverage automatic typeclass
 derivation. I hope this blog post helps make your team more productive with
 Scala.
+
+[Shapeless]: https://github.com/milessabin/shapeless