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.
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> wrote:
> 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 > -- > You received this message because you are subscribed to the Google Groups "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
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
On Mon, Oct 18, 2010 at 5:11 AM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
> 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> > wrote:
> 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
> -- > You received this message because you are subscribed to the Google Groups > "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to > play-framework+unsubscribe@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/play-framework?hl=en.
> 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
> 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>
> > wrote:
> > 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
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-framework@googlegroups.com.
> > To unsubscribe from this group, send email to
> > play-framework+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/play-framework?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-framework@googlegroups.com.
> > To unsubscribe from this group, send email to
> > play-framework+unsubscribe@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/play-framework?hl=en.
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?
>> 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
>> 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> >> > wrote:
>> > 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
>> > -- >> > You received this message because you are subscribed to the Google Groups >> > "play-framework" group. >> > To post to this group, send email to play-framework@googlegroups.com. >> > To unsubscribe from this group, send email to >> > play-framework+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> >http://groups.google.com/group/play-framework?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google Groups >> > "play-framework" group. >> > To post to this group, send email to play-framework@googlegroups.com. >> > To unsubscribe from this group, send email to >> > play-framework+unsubscribe@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com> >> > . >> > For more options, visit this group at >> >http://groups.google.com/group/play-framework?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "play-framework" group. > To post to this group, send email to play-framework@googlegroups.com. > To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
On Mon, Oct 18, 2010 at 6:16 PM, Guillaume Bort <guillaume.b...@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.
