Compiling is very slow with scala-0.7.3 and newer

119 views
Skip to first unread message

Matt Hildebrand

unread,
Oct 18, 2010, 1:45:34 AM10/18/10
to play-fr...@googlegroups.com
Hello,

Has anyone else found that developing Scala applications is *much* slower with recent versions of Play & the scala module?

Some details:
- Compile time has increased from about one second to approximately 12 seconds... on every single code change.  This is just from editing a .scala file and pressing reload in the browser.  Needless to say, this is a huge drain on productivity.
- The application in question is small:  eight controllers, 44 Scala source files, no Java source files, and under 2,000 lines of code (including whitespace and comments).
- A minimal application obtained with "play new foo --with scala" exhibits no noticeable slowdown.
- Play is running in dev mode.
- I've done "play clean" each time when switching between versions of Play & the scala module.

The following combinations are fast:
- Play 1.1-unstable-r915 with scala-0.6.
- Play 1.1-unstable-r915 with scala-0.7.
- Play 1.1-unstable-r915 with scala-0.7.1.
- Play 1.1-unstable-r915 with scala-0.7.2.

The following combinations are slow:
- Play 1.1-beta1 with scala-0.7.3.
- Play 1.1-RC2 with scala-head.

Is this slowdown a known issue?  I could not find mention of it in the mailing list archives or in the ticket tracker.

Conjecture:  Perhaps *all* .scala files are being rebuilt each time?  The log output from older versions of the scala module showed that only affected files were being rebuilt, but since scala-0.7.3 this log message is absent and compiling is slow.

Thank you,
-Matt

Guillaume Bort

unread,
Oct 18, 2010, 5:11:59 AM10/18/10
to play-fr...@googlegroups.com
Hi,

I've fixed a bug since 0.7.3 in the transitive dependencies computation. Before that only the modified file was recompiled. But it is not correct because types defined in one file can depend of types defined in another file. 

So changing a single file can at the end recompile several files. 

Well perhaps there is a problem somewhere, I will check tonight. 

But can you make a little test? If you define a scala file that doesn't depend of any other types of your application, do any modification to this file still trigger a complete recompilation?

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

Matt Hildebrand

unread,
Oct 18, 2010, 1:23:32 PM10/18/10
to play-fr...@googlegroups.com
Salut Guillaume,

I've looked into this some more, using Play 1.1-RC2 and scala-head.

1.  In the test you suggested, the slowness is still present.  I added the following trivial controller, as Foo.scala, to the application:

package controllers
import play.mvc.Controller

object Foo extends Controller {
  def index() = "foo"
}

This code does not depend on any of the application's types, but modifying Foo.scala results in a long delay during the next page load.

2.  I increased the logging verbosity to TRACE level.  This yielded some clues:

(a) First, the scala module is compiling *only* Foo.scala when it changes -- not all .scala files.  The log message is:

12:59:22,204 TRACE ~ Compiling [Foo.scala]

(b) Compiling Foo.scala takes only 392 milliseconds, and then messages like this one start appearing:

12:59:22,596 TRACE ~ 0ms to apply SigEnhancer to dao.old.ItemDaoImpl$$anonfun$findAll$1

(c) The log output shows that the long delay occurs after the classes are all loaded and before the "init: end true" message appears:

12:59,25,112 TRACE ~ 0ms to apply DocViewerPlugin@16d739de to controllers.items.Images$$anonfun$2
12:59:25,114 TRACE ~ controllers.items.Images$$anonfun$2 cached
12:59:38,834 TRACE ~ init: end true

Note the 13-second delay between the last two messages.  I'm not familiar with the code, but will try to find time to look into it to see what's going on between those two messages.

Anyway, I hope this helps.  If there's anything else I can do to help solve this, just let me know.

Thank you,
-Matt

peter hausel

unread,
Oct 18, 2010, 3:40:33 PM10/18/10
to play-framework
Thanks Matt, we will look into this. Peter
> On Mon, Oct 18, 2010 at 5:11 AM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
>
>
>
> > Hi,
>
> > I've fixed a bug since 0.7.3 in the transitive dependencies computation.
> > Before that only the modified file was recompiled. But it is not correct
> > because types defined in one file can depend of types defined in another
> > file.
>
> > So changing a single file can at the end recompile several files.
>
> > Well perhaps there is a problem somewhere, I will check tonight.
>
> > But can you make a little test? If you define a scala file that doesn't
> > depend of any other types of your application, do any modification to this
> > file still trigger a complete recompilation?
>
> > Sent from my iPhone
>
> > On Oct 18, 2010, at 7:45, Matt Hildebrand <matt.hildebr...@gmail.com>
> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

Guillaume Bort

unread,
Oct 18, 2010, 6:16:58 PM10/18/10
to play-fr...@googlegroups.com
Ok so, only needed classes were recompiled but too much (in fact all)
classes where hotswapped in the JVM. I think that I've fixed the
problem. Can you check the latest from github?

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,
write guillau...@gmail.com

Matt Hildebrand

unread,
Oct 18, 2010, 7:18:19 PM10/18/10
to play-fr...@googlegroups.com
On Mon, Oct 18, 2010 at 6:16 PM, Guillaume Bort <guillau...@gmail.com> wrote:
Ok so, only needed classes were recompiled but too much (in fact all)
classes where hotswapped in the JVM. I think that I've fixed the
problem. Can you check the latest from github?

Success!  It's fast again.  Thank you for the quick fix.

Best,
-Matt
Reply all
Reply to author
Forward
0 new messages