From b094df4a6a6cf1bf7eeb36d842970aa8b3d94d5f Mon Sep 17 00:00:00 2001 From: Li Haoyi Date: Wed, 4 Feb 2015 05:31:48 -0800 Subject: first attempt at updating things for 0.6.0 --- book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex') diff --git a/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex b/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex index 5d91b62..ece6215 100644 --- a/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex +++ b/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex @@ -134,7 +134,7 @@ @li @b{Inlining}: under some circumstances, the optimizer inlines the implementation of methods at call sites. For example, it does so for all "small enough" methods. This typically reduces the code size by a small amount, but offers a several-times speedup of the generated code by inlining away much of the overhead from the abstractions (implicit-conversions, higher-order-functions, etc.) in Scala's standard library. @li - @b{Constant-folding}: due to inlining and other optimizations, some variables that could have arbitrary are known to contain a constant. These variables are replaced by their respective constants, which, in turn, can trigger more optimizations. + @b{Constant-folding}: due to inlining and other optimizations, some variables that could have arbitrary values are known to contain a constant. These variables are replaced by their respective constants, which, in turn, can trigger more optimizations. @li @b{Closure elimination}: probably one of the most important optimizations. When inlining a higher-order method such as @code{map}, the optimizer can in turn inline the anonymous function inside the body of the loop, effectively turning polymorphic dispatch with closures into bare-metal loops. @p -- cgit v1.2.3