any tips to deal with scala compilation time?

[Alberto SOUZA]

Hi,

What have you been doing about the scala compilation time? I mean, i know that is a overhead brought by the extra steps needed to generate the bytecode but, in medium/big project, the compilation becomes a problem that we have to deal. Is there any sbt plugin to make the compilation faster? Are you using the continuos compilation? Another strategy? 

Thanks,

Alberto

[HamsterofDeath]

i use intellij which offer incremental compilation and manages a
compilation server in background to save startup time.
the same goes for eclipse.
btw, how long does it take for you to compile? i had a 500 files/2500
classes project which took 30 seconds for a full compilation

[Andreas Joseph Krogh]

I use an IDE, IntelliJ IDEA, which doesn't require me to compile all the
time. And yes, when I do compile, I use FSC from within IDEA (check "use
internal FSC" in all Scala-facets).

--
Andreas Joseph Krogh<and...@officenet.no> - mob: +47 909 56 963
Senior Software Developer / CEO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

[Alberto SOUZA]

sometimes, more than a minute... We were using intellij and we changed by the eclipse. I did not try the fsc compiler to make things faster. Is there a way to configure xsbt for use the fsc instead of  incremental compile? 

Alberto

[Kevin Wright]

All that fsc does is to keep the compiler "warm" in a JVM, so that you don't incur the JVM startup cost and don't have to wait for hotspots to be optimised with each invocation of scalac.

The best way to do this with sbt is to launch the sbt console and then compile from within the console.

So:

sbt

> compile

> compile

> compile

instead of:

sbt compile

sbt compile

sbt compile

This will then perform even better than fsc, as sbt can perform extra dependency analysis, allowing it to *only* recompile what is truly necessary.

This can even be taken all the way to continuous compilation, in which sbt monitors for any file changes, and automatically recompiles in response:

sbt

> ~compile

or continuous testing (tests are only re-run if a dependency has changed):

sbt ~test

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[HamsterofDeath]

i didn't try sbt, but how can it be faster? technically, it is the same, isn't it? a "warm compiler". and idea should take care of the dependency analysis. i can make a change, press make and idea only compiles a few classes instead of everything.

[Andreas Joseph Krogh]

On 03/04/2012 06:03 PM, Alberto SOUZA wrote:
> sometimes, more than a minute... We were using intellij and we changed
> by the eclipse. I did not try the fsc compiler to make things faster.
> Is there a way to configure xsbt for use the fsc instead of
> incremental compile?

Why didn't you try FSC? It makes a *very* big difference.
I know nothing about xsbt.

[Alberto SOUZA]

I know, and there is a problem in our project, i don't know if it is because we use a lot of implicit methods, but sometimes, when we change just one file, the sbt recompiles almost every file in our project. It seems to me, that the graph between the classes is a little bit differente when you use a lot of implicits.

Thanks,

Alberto

[HamsterofDeath]

how does the sbt know which files to comoile, anyway?
i understand how intellij knows, they parse the whole project. but how does the sbt do it? maybe they have to compile more just to be sure?

[Josh Suereth]

It hashes the public/protected API of classes and tracks dependencies using a compiler plugin.  If a hash of a class changed, dependent files must be recompiled.   It does this through potentially several compiler runs.

[Kevin Wright]

SBT keeps hold of a dependency tree, just as any IDE does.

Unlike IntelliJ though, it works at the class level and not the source-file level.

This allows sbt to avoid recompiling inner classes, anonymous classes, and multiple classes defined in the same file, which means that it has the potential to do less work and so be faster.

[Jason Zaugg]

On Sun, Mar 4, 2012 at 10:28 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> SBT keeps hold of a dependency tree, just as any IDE does.
>
> Unlike IntelliJ though, it works at the class level and not the source-file
> level.
>
> This allows sbt to avoid recompiling inner classes, anonymous classes, and
> multiple classes defined in the same file, which means that it has the
> potential to do less work and so be faster.

SBT also works at the source file level. But if your change to a file
doesn't change the public API of a source file, downstream files won't
be recompiled. It takes correctness very seriously -- you can rely on
an incremental build giving the same result as a clean build in just
about all cases.

To troubleshoot unexpected recompilation, run `last compile`. You will
see which change triggered the recompilation of the next batch of
files. I have found that use of package objects and implicits tends to
introduce unwanted dependencies into your compilation graph.

-jason

[Alberto SOUZA]

In our project here, we are using a lot of implicit conversions. We think that is the problem... What do you know about that? We do not know if, the fact that we are using implicits makes the compilation slower?

Thanks,

Alberto

[Jason Zaugg]

On Fri, Mar 9, 2012 at 7:23 PM, Alberto SOUZA <alot...@gmail.com> wrote:
> In our project here, we are using a lot of implicit conversions. We think
> that is the problem... What do you know about that? We do not know if, the
> fact that we are using implicits makes the compilation slower?

Add -Ystatistics to your compiler options measure how long much time
is spent in implicit resolution.

-jason

[Matthew Pocock]

I've noticed that implicits do really slow things down. It's not just you.