سؤال

I'm using Eclipse 4.3.2 Scala IDE 3.0.3 and so far it's been fine. Lately however I've started using Slick 2.0.1 code generator and since there are some pretty heavy tables on my database (up to 200 columns), Slick code generator uses "HList implementation for overcoming Scala’s tuple size limit".

This causes the whole load of problems:

  1. Opening the file containing code generator generated classes freezes eclipse for a few minutes.
  2. I'm often getting eclipse Error in Scala compiler java.lang.StackOverflowError at which point I am advised to close the application...
  3. "Content Assist" crashes with the following error:

The 'Scala Completion Proposal Computer' proposal computer from the 'org-scala-ide.sdt.core' plug-in did not complete normally. Unable to instantiate the extension.

4."Updating occurrence annotations" runs for ages

I'm guessing all these problems are memory related (let me know otherwise), so I've tried increasing memory settings on eclipse.ini:

-Xss8M
-XX:MaxPermSize=1024m #this one seems to be irrelevant since I'm running Java 8
-Xms512m
-Xmx4096m

Is there anything else I can do to make my workflow bearable?

My stack:

Scala 2.10.4 / Play Framework 2.2.2 / Java 8 / Ubuntu 13.10 64 Bit

UPDATE: This is the file causing the problem: http://pastebin.com/BDhhPHXB

So far I've noticed this: Opening the file / saving it / compiling it / using code suggestions takes roughly 70 seconds every time. So I'm guessing the code of this file is run against the compiler on pretty much any action involving it?

هل كانت مفيدة؟

المحلول

As for the crashes, I have been able to reproduce a compiler stack overflow with your code exactly once and I reported a bug: https://issues.scala-lang.org/browse/SI-8477 Increasing the java stack size may help, but it is suspicious that it only happens sporadically.

Regarding the freezes and the compile time: I investigated compile times with Slick HLists and eventhough they have gotten a lot better in Scala 2.10.4, they still seem to be slow (and actually exponential) when we get to sizes of a few hundreds elements as with your tables, that have a few hundred columns. This may be a Scala compiler bug or there may just be room for improvement or maybe nothing could be done in the compiler. At best Slick could work around that if we find multiple way to express the same thing and one is faster then the existing one, but that's speculation. I produced a minimized code example and requested an improvement of the compiler: https://issues.scala-lang.org/browse/SI-8478

UPDATE: We are working on a workaround for Slick. Not done yet. https://github.com/slick/slick/pull/749

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top