Java 컴파일 속도 대 Scala 컴파일 속도

Java 컴파일 속도 대 Scala 컴파일 속도

---

나는 한동안 Scala에서 프로그래밍을 해왔고 나는 그것을 좋아하지만 내가 짜증나는 것은 프로그램을 컴파일하는 데 걸리는 시간이다. 작은 것 같지만 Java를 사용하면 프로그램을 약간 변경하고 netbeans에서 실행 버튼을 클릭하면 BOOM이 실행되고 시간이 지남에 따라 scala에서 컴파일하는 데 많은 시간이 소요되는 것 같습니다. 많은 대규모 프로젝트에서 컴파일하는 데 걸리는 시간 때문에 스크립팅 언어가 매우 중요해 졌다고 들었습니다. Java를 사용할 때 발생하지 않았던 필요성이 있습니다.

그러나 나는 내가 이해하는대로 다른 컴파일 언어보다 빠르며 Scala로 전환 한 이유 때문에 빠르다는 Java에서 왔습니다 (매우 간단한 언어입니다).

그래서 물어보고 싶었습니다. Scala를 더 빨리 컴파일하고 scalac이 javac만큼 빠를 것입니다.

---

Scala 컴파일러는 Java보다 더 정교하여 유형 추론, 암시 적 변환 및 훨씬 더 강력한 유형 시스템을 제공합니다. 이러한 기능은 무료로 제공되지 않으므로 scalac이 javac만큼 빠르지 않을 것입니다. 이것은 작업을 수행하는 프로그래머와 작업을 수행하는 컴파일러 간의 절충안을 반영합니다.

즉, 컴파일 시간은 이미 Scala 2.7에서 Scala 2.8로 눈에 띄게 개선되었으며, 2.8에 먼지가 정착되었으므로 개선이 계속 될 것으로 예상합니다. 이 페이지 는 Scala 컴파일러의 성능을 향상시키기위한 지속적인 노력과 아이디어를 문서화합니다.

Martin Odersky는 그의 답변에서 훨씬 더 자세한 내용을 제공합니다.

---

Scala 컴파일러의 속도 (부족)에는 두 가지 측면이 있습니다.

1. 시작 오버 헤드 증가

   • Scalac 자체는로드 및 jit 컴파일해야하는 많은 클래스로 구성됩니다.

   • Scalac은 모든 루트 패키지 및 파일에 대한 클래스 경로를 검색해야합니다. 클래스 경로의 크기에 따라 1 ~ 3 초 더 걸릴 수 있습니다.

   전반적으로 4-8 초의 scalac의 시작 오버 헤드가 예상되며 디스크 캐시가 채워지지 않도록 처음 실행할 경우 더 길어집니다.

   시작 오버 헤드에 대한 Scala의 대답은 fsc를 사용하거나 sbt로 연속 빌드를 수행하는 것입니다. IntelliJ는 두 옵션 중 하나를 사용하도록 구성해야합니다. 그렇지 않으면 작은 파일의 경우에도 오버 헤드가 너무 큽니다.

2. 컴파일 속도가 느립니다. Scalac은 약 500 개에서 최대 1000 개의 라인 / 초를 관리합니다. Javac은 약 10 배를 관리합니다. 이에 대한 몇 가지 이유가 있습니다.

   • 유형 추론은 특히 암시 적 검색과 관련된 경우 비용이 많이 듭니다.

   • Scalac은 유형 검사를 두 번 수행해야합니다. Scala의 규칙에 따라 한 번, Java의 규칙에 따라 삭제 한 후 두 번째.

   • 유형 검사 외에도 Scala에서 Java로 이동하는 데 약 15 개의 변환 단계가 있으며 모두 시간이 걸립니다.

   • Scala는 일반적으로 Java보다 주어진 파일 크기 당 더 많은 클래스를 생성합니다. 특히 기능적 관용구가 많이 사용되는 경우 더욱 그렇습니다. 바이트 코드 생성 및 클래스 작성에는 시간이 걸립니다.

   반면에 1000 줄 Scala 프로그램은 2-3K 줄 Java 프로그램에 해당 할 수 있으므로 초당 줄로 계산할 때 느린 속도 중 일부는 줄당 더 많은 기능과 균형을 이루어야합니다.

   우리는 속도 향상을 위해 노력하고 있지만 (예를 들어, 클래스 파일을 병렬로 생성함으로써),이면에서 기적을 기대할 수 없습니다. Scalac은 javac만큼 빠르지 않습니다. 나는 해결책이 좋은 의존성 분석과 함께 fsc와 같은 컴파일 서버에있을 것이라고 믿는다. 그래서 최소한의 파일 세트 만 재 컴파일되어야한다. 우리도 그것에 대해 연구하고 있습니다.

---

Scala 컴파일은 컴파일하는 데 Java보다 적어도 10 배 더 오래 걸립니다. 그 이유는 다음과 같습니다.

1. 명명 규칙 (파일 XY.scala파일은 호출 된 클래스를 포함 할 필요가 없으며 XY여러 최상위 클래스를 포함 할 수 있습니다). 따라서 컴파일러는 주어진 클래스 / 특성 / 객체 식별자를 찾기 위해 더 많은 소스 파일을 검색해야 할 수 있습니다.
2. 암시 적-암시 적을 많이 사용한다는 것은 컴파일러가 주어진 메서드에 대해 범위 내 암시 적 변환을 검색하고 "올바른"메서드를 찾기 위해 순위를 지정해야 함을 의미합니다. ( 즉, 컴파일러는 메서드를 찾을 때 검색 도메인이 엄청나게 증가합니다. )
3. 유형 시스템-스칼라 유형 시스템은 Java보다 훨씬 복잡하므로 CPU 시간이 더 많이 걸립니다.
4. 유형 추론-유형 추론은 계산 비용이 많이 들고 javac전혀 수행 할 필요가없는 작업입니다.
5. scalacGenICode 컴파일 단계 에서 매직 키 조합 CTRL-ALT-F12를 사용하여 볼 수있는 완전 무장 및 작전 전투 스테이션의 8 비트 시뮬레이터가 포함되어 있습니다 .

---

Scala를 수행하는 가장 좋은 방법은 IDEA와 SBT를 사용하는 것입니다. 기본 SBT 프로젝트 (원하는 경우 수행)를 설정하고 자동 컴파일 모드 (command ~compile) 에서 실행하고 프로젝트를 저장하면 SBT가 다시 컴파일합니다.

또한 IDEA 용 SBT 플러그인을 사용하고 각 실행 구성에 SBT 작업을 연결할 수 있습니다. SBT 플러그인은 또한 IDEA 내에서 대화 형 SBT 콘솔을 제공합니다.

어느 쪽이든 (외부에서 실행되는 SBT 또는 SBT 플러그인) SBT는 계속 실행되므로 프로젝트를 빌드하는 데 사용되는 모든 클래스가 "워밍업"되고 JIT가 적용되고 시작 오버 헤드가 제거됩니다. 또한 SBT는 필요한 소스 파일 만 컴파일합니다. Scala 프로그램을 빌드하는 가장 효율적인 방법입니다.

---

Scala-IDE (Eclipse) 의 최신 개정판은 증분 컴파일을 관리하는 데 훨씬 좋습니다.

자세한 내용은 " 최고의 Scala 빌드 시스템은 무엇입니까? "를 참조하십시오.

---

다른 해결책은 fsc-Scala 2 언어 용 Fast 오프라인 컴파일러 (이 블로그 게시물에 설명 된 대로)를 IDE의 빌더로 통합하는 것입니다.

하지만,하지에 직접 이클립스, 것처럼 다니엘 스피 웍이 코멘트에 언급 :

Eclipse가 이미 표면 아래에서 FSC를 사용하고 있기 때문에 Eclipse 내에서 직접 FSC를 사용해서는 안됩니다.
FSC는 기본적으로 Eclipse에서 Scala 프로젝트를 컴파일하는 데 사용하는 메커니즘 인 상주 컴파일러 위에있는 얇은 레이어입니다.

---

Finally, as Jackson Davis reminds me in the comments:

sbt (Simple build Tool) also include some kind of "incremental" compilation (through triggered execution), even though it is not perfect, and enhanced incremental compilation is in the work for the upcoming 0.9 sbt version.

---

Use fsc - it is a fast scala compiler that sits as a background task and does not need loading all the time. It can reuse previous compiler instance.

I'm not sure if Netbeans scala plugin supports fsc (documentation says so), but I couldn't make it work. Try nightly builds of the plugin.

---

You can use the JRebel plugin which is free for Scala. So you can kind of "develop in the debugger" and JRebel would always reload the changed class on the spot.

I read some statement somewhere by Martin Odersky himself where he is saying that the searches for implicits (the compiler must make sure there is not more than one single implicit for the same conversion to rule out ambiguities) can keep the compiler busy. So it might be a good idea to handle implicits with care.

If it doesn't have to be 100% Scala, but also something similar, you might give Kotlin a try.

-- Oliver

---

I'm sure this will be down-voted, but extremely rapid turn-around is not always conducive to quality or productivity.

시간을내어 더 신중하게 생각하고 더 적은 개발 마이크로 사이클을 실행하십시오. 좋은 Scala 코드는 밀도가 높고 더 필수적입니다 (즉, 부수적 인 세부 사항과 복잡성이 없음). 더 많은 생각이 필요하며 적어도 처음에는 시간이 걸립니다. 개별적으로 조금 더 긴 코드 / 테스트 / 디버그주기를 줄이고 생산성과 작업 품질을 향상시킬 수 있습니다.

요컨대 : Scala에 더 적합한 최적의 작업 패턴을 찾으십시오.

참고 URL : https://stackoverflow.com/questions/3606591/why-does-intellij-idea-compile-scala-so-slowly