Velocidade de compilação Java vs velocidade de compilação Scala

Eu tenho programado em Scala por um tempo e gosto disso, mas uma coisa que me incomoda é o tempo que leva para compilar programas. Parece uma coisa pequena, mas com Java eu ​​poderia fazer pequenas alterações em meu programa, clicar no botão executar no netbeans e BOOM, ele está rodando, e com o tempo a compilação em scala parece consumir muito tempo. Ouvi dizer que, em muitos projetos grandes, uma linguagem de script se torna muito importante por causa do tempo que leva para compilar, uma necessidade que não vi surgindo quando estava usando Java.

Mas estou vindo de Java que, pelo que entendi, é mais rápido do que qualquer outra linguagem compilada, e é rápido por causa dos motivos que mudei para Scala (é uma linguagem muito simples).

Então, eu queria perguntar, posso fazer o Scala compilar mais rápido e o scalac será sempre tão rápido quanto o javac.

O compilador Scala é mais sofisticado que o Java, fornecendo inferência de tipos, conversão implícita e um sistema de tipos muito mais poderoso. Esses recursos não vêm de graça, então eu não esperaria que o scalac fosse tão rápido quanto o javac. Isso reflete uma compensação entre o programador que faz o trabalho e o compilador que faz o trabalho.

Dito isso, os tempos de compilação já melhoraram visivelmente indo do Scala 2.7 para o Scala 2.8, e espero que as melhorias continuem agora que a poeira baixou no 2.8. Esta página documenta alguns dos esforços e ideias em andamento para melhorar o desempenho do compilador Scala.

Martin Odersky fornece muito mais detalhes em sua resposta.

Existem dois aspectos na (falta de) velocidade do compilador Scala.

1. Maior sobrecarga de inicialização

   • O próprio Scalac consiste em um monte de classes que devem ser carregadas e compiladas por jit

   • O Scalac tem que pesquisar o classpath para todos os pacotes e arquivos raiz. Dependendo do tamanho do seu caminho de classe, isso pode levar de um a três segundos extras.

   No geral, espere uma sobrecarga de inicialização de scalac de 4-8 segundos, mais se você executá-lo pela primeira vez, de forma que os caches de disco não sejam preenchidos.

   A resposta do Scala para a sobrecarga de inicialização é usar fsc ou fazer construção contínua com sbt. O IntelliJ precisa ser configurado para usar qualquer uma das opções, caso contrário, sua sobrecarga, mesmo para arquivos pequenos, é excessivamente grande.

2. Velocidade de compilação mais lenta. O Scalac gerencia cerca de 500 a 1000 linhas / s. Javac consegue cerca de 10 vezes isso. Há várias razões para isso.

   • A inferência de tipo é cara, principalmente se envolver pesquisa implícita.

   • O Scalac tem que fazer a verificação de tipo duas vezes; uma vez de acordo com as regras do Scala e uma segunda vez após o apagamento de acordo com as regras do Java.

   • Além da verificação de tipo, há cerca de 15 etapas de transformação para ir de Scala para Java, que levam tempo.

   • Scala normalmente gera muito mais classes por tamanho de arquivo determinado do que Java, em particular se idiomas funcionais são muito usados. A geração de bytecode e a escrita de classes levam tempo.

   Por outro lado, um programa Scala de 1000 linhas pode corresponder a um programa Java de 2-3K linhas, portanto, parte da velocidade mais lenta quando contada em linhas por segundo deve ser balanceada com mais funcionalidade por linha.

   Estamos trabalhando para melhorar a velocidade (por exemplo, gerando arquivos de classe em paralelo), mas não se pode esperar milagres nessa frente. Scalac nunca será tão rápido quanto javac. Acredito que a solução estará na compilação de servidores como o fsc em conjunto com uma boa análise de dependência, de modo que apenas o conjunto mínimo de arquivos precise ser recompilado. Estamos trabalhando nisso também.

Você deve estar ciente de que a compilação Scala leva pelo menos uma ordem de magnitude mais do que Java para ser compilada. Os motivos para isso são os seguintes:

1. Convenções de nomenclatura (um arquivo XY.scalanão precisa conter uma classe chamada XYe pode conter várias classes de nível superior). O compilador pode, portanto, ter que pesquisar mais arquivos de origem para encontrar um determinado identificador de classe / característica / objeto.
2. Implícitos - o uso pesado de implícitos significa que o compilador precisa pesquisar qualquer conversão implícita no escopo para um determinado método e classificá-los para encontrar o "correto". ( ou seja, o compilador tem um domínio de pesquisa enormemente aumentado ao localizar um método. )
3. O sistema de tipos - o sistema de tipos scala é muito mais complicado do que o de Java e, portanto, leva mais tempo de CPU.
4. Inferência de tipo - a inferência de tipo é computacionalmente cara e um trabalho que javacnão precisa ser feito
5. scalacinclui um simulador de 8 bits de uma estação de batalha totalmente armada e operacional, visível usando a combinação de teclas mágicas CTRL-ALT-F12 durante a fase de compilação do GenICode .

A melhor forma de fazer Scala é com IDEA e SBT. Configure um projeto SBT elementar (que ele fará por você, se quiser) e execute-o no modo de compilação automática (comando ~compile) e quando você salvar seu projeto, o SBT o recompilará.

Você também pode usar o plug-in SBT para IDEA e anexar uma ação SBT a cada uma de suas configurações de execução. O plug-in SBT também oferece um console SBT interativo dentro do IDEA.

De qualquer forma (SBT rodando externamente ou plug-in SBT), o SBT permanece rodando e assim todas as classes usadas na construção do seu projeto são "aquecidas" e JIT-ed e o overhead de inicialização é eliminado. Além disso, o SBT compila apenas os arquivos de origem que precisam dele. É de longe a maneira mais eficiente de construir programas Scala.

As últimas revisões do Scala-IDE (Eclipse) são muito melhores no gerenciamento de compilação incremental.

Consulte “ Qual é o melhor sistema de compilação Scala? ” Para mais informações.

A outra solução é integrar fsc - Compilador offline rápido para a linguagem Scala 2 - (conforme ilustrado nesta postagem do blog ) como um construtor em seu IDE.

Mas não diretamente no Eclipse, como Daniel Spiewak menciona nos comentários:

Você não deve usar o FSC diretamente no Eclipse, apenas porque o Eclipse já está usando o FSC sob a superfície.
O FSC é basicamente uma camada fina sobre o compilador residente, que é precisamente o mecanismo usado pelo Eclipse para compilar projetos Scala.

Finalmente, como Jackson Davis me lembra nos comentários:

sbt (ferramenta de construção simples) também inclui algum tipo de compilação "incremental" (por meio de execução acionada ), embora não seja perfeita , e a compilação incremental aprimorada está em andamento para a próxima versão 0.9 sbt.

Use fsc - é um compilador de scala rápido que fica como uma tarefa em segundo plano e não precisa ser carregado o tempo todo. Ele pode reutilizar a instância do compilador anterior.

Não tenho certeza se o plug-in Scala do Netbeans suporta fsc (a documentação diz isso), mas não consegui fazer funcionar. Experimente compilações noturnas do plugin.

Você pode usar o plugin JRebel, que é gratuito para Scala. Assim, você pode "desenvolver no depurador" e o JRebel sempre recarregará a classe alterada no local.

Eu li alguma declaração em algum lugar do próprio Martin Odersky onde ele está dizendo que as buscas por implícitos (o compilador deve se certificar de que não há mais de um implícito único para a mesma conversão para descartar ambigüidades) podem manter o compilador ocupado. Portanto, pode ser uma boa ideia lidar com os implícitos com cuidado.

Se não precisa ser 100% Scala, mas também algo semelhante, você pode dar Kotlin experimentar o .

- Oliver

Tenho certeza de que isso terá uma votação negativa, mas a reversão extremamente rápida nem sempre conduz à qualidade ou à produtividade.

Reserve um tempo para pensar com mais cuidado e executar menos microciclos de desenvolvimento. O bom código Scala é mais denso e essencial (ou seja, livre de detalhes incidentais e complexidade). Exige mais reflexão e isso leva tempo (pelo menos no início). Você pode progredir bem com menos ciclos de código / teste / depuração que são individualmente um pouco mais longos e ainda melhorar sua produtividade e a qualidade de seu trabalho.

Resumindo: Procure um padrão de trabalho ideal mais adequado ao Scala.