Slow Compile Specs - This may be of interest

[theGhost]

Hi
At the last meeting I think I recall Jeremy expressing some disappointment as to the compile time with Specs test suites.
This may be a red herring in your case but in Scalawags #2 Daniel Spiewak commented on slow compile times due to a large number of lamdas in a single file and specifically mentioned large Specs suites as an example. He solved the problem by splitting into separate files.

If you want to check out exactly what was said:

Scalawags #2

http://www.youtube.com/watch?v=nblL4mjoEjs.  at 46:07 mins.

John

PS - for those who have not checked out Scalawags it's quite amusing and informative, if at times not overly concise  :-).

[etorreborre]

Hi,

Please note that Bill Venners has done some analysis of the compilation times for Scalatest, specs2 and JUnit.

It turns out that there is an easy optimisation to do which I did for the latest specs2 versions and which you can do on your own code if necessary: transform the "Specification" traits into abstract classes. The net effect should be 0.5s per class.

Now, among the other things which are slowing down the compilation there are:

 - implicit search

 - by-name parameters

You can optimise this by building your own base "Spec" trait just inheriting from BaseSpecification and add matchers traits or other functionalities as you need them.

Cheers,

Eric.

[Jem]

Thanks guys. I don't think Specs is my issue. I've got something funky with the IDE wherein each time I change a method signature (in Java) scalac kicks in and recompiles everything.

--
You received this message because you are subscribed to the Google Groups "Melbourne Scala User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-melb+...@googlegroups.com.
To post to this group, send an email to scala...@googlegroups.com.
Visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.