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

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

하지만 저는 Java에서 왔는데, 다른 컴파일 된 언어보다 빠르며 Scala로 전환 한 이유 때문에 빠릅니다 (매우 간단한 언어입니다).

그래서 물어보고 싶었습니다. 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 프로젝트를 컴파일하는 데 사용하는 메커니즘 인 상주 컴파일러 위에 얇은 레이어입니다.

마지막으로, Jackson Davis 는 댓글에서 다음 과 같이 상기시켜줍니다.

sbt (Simple build Tool) 에는 일종의 "증분"컴파일도 포함됩니다. 완벽하지 않더라도 트리거 된 실행을 ) 이 포함되어 있으며 향후 0.9 sbt 버전에서 개선 된 증분 컴파일 작업이 진행 중입니다.

fsc 사용 -백그라운드 작업으로 사용되며 항상로드 할 필요가없는 빠른 스칼라 컴파일러입니다. 이전 컴파일러 인스턴스를 재사용 할 수 있습니다.

Netbeans scala 플러그인이 fsc를 지원하는지 확실하지 않지만 (문서에 나와 있음) 작동하도록 만들 수 없습니다. 플러그인의 야간 빌드를 사용해보십시오.

Scala에서 무료로 제공되는 JRebel 플러그인을 사용할 수 있습니다. 따라서 "디버거에서 개발"할 수 있으며 JRebel은 항상 그 자리에서 변경된 클래스를 다시로드합니다.

나는 Martin Odersky 자신이 암시 적 (implicits)에 대한 검색 (컴파일러는 모호성을 배제하기 위해 동일한 변환에 대해 하나 이상의 암시 적이 없는지 확인해야 함)이 컴파일러를 바쁘게 유지할 수 있다고 말한 몇 가지 진술을 읽었습니다. 따라서 암시적인 내용을주의해서 처리하는 것이 좋습니다.

100 % 스칼라 일 필요는 없지만 비슷한 것이라면 Kotlin 을 사용해 볼 수 있습니다.

-올리버

나는 이것이 반대 투표가 될 것이라고 확신하지만, 극도로 빠른 처리가 항상 품질이나 생산성에 도움이되는 것은 아닙니다.

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

요컨대 : Scala에 더 적합한 최적의 작업 패턴을 찾습니다.