성능

리스크립트는 설치와 빌드 그리고 실행 시점의 성능을 중요한 기능으로 여깁니다. 성능은 신경 쓰이기 전까지 눈에 띄지 않는 것들 중 하나입니다.

여러분의 빌드를 분석하세요

때때로 혼란스러운 인프라 설정으로 인하여 빌드가 느려질 수 있습니다. bstracing 을 이용하여 빌드 성능에 대한 상호작용 가능한 시각화를 제공합니다.

./node_modules/.bin/bstracing

리스크립트 프로젝트 루트에서 위 명령을 실행하세요. chrome://tracing 으로 드래그 앤 드롭 할 수 있는 JSON 파일을 뱉어냅니다.

조금 더 알아보기

리스크립트는 Ninja를 빌드 시스템으로 사용합니다. Ninja는 Make와 비슷하지만 크로스플랫폼, 최소화, 성능에 초점을 둔 본격적인 빌드 시스템보다 저수준의 빌딩 블럭에 가깝습니다. 이와 관련해 Ninja는 rescript 에 대한 훌륭한 세부 구현입니다.

리스크립트는 bsconfig.json 파일을 읽고 lib/bs 에 Ninja 빌드 파일을 만듭니다. 이 파일에는 저수준의 컴파일러 명령, 네임스페이스 규칙, 중간 단계 아티팩트 생성 및 기타 내용이 있습니다. 그 다음 실제 빌드를 위해 ninja 를 실행합니다.

자바스크립트 래퍼

rescript 자체는 일부 기타 작업과 감시자를 처리하는 Node.js 래퍼입니다. 저수준의 감시자가 없는 빠른 네이티브 rescript는 rescript.exe 입니다. node_modules/rescript/{여러분의-플랫폼}/rescript.exe 에 있습니다.

여러분이 감시자가 필요하지 않다면, rescript.exe를 실행하면 됩니다. 이는 Node.js 의 100ms정도의 긴 시작 시간을 피할 수 있습니다. 우리의 에디터 플러그인은 다 나은 성능을 위해 네이티브 rescript.exe 파일을 찾아 실행합니다.

숫자

작은 프로젝트의 원시 rescript.exe 빌드는 반드시 70ms 이내여야합니다. 이것은 감시자와 함께 제공되는 자바스크립트 rescript 래퍼를 사용할 때 두배가 되는데, 이는 매 변경마다 수동으로 빌드를 하지 않기 때문에 실제로 더 빠릅니다 (프로그래밍 방식 사용을 위해서는 원시 rescript.exe를 선택해야 합니다. 예: 기존 자바스크립트 빌드 파이프라인에 리스크립트를 삽입하는 경우를 말합니다.)

No-op 빌드 (파일이 변경되지 않음)의 경우에는 약 15ms 이내여야 합니다. 프로젝트에서 한 파일의 증분 재빌드(곧 설명합니다)도 약 70ms 이내입니다.

아티팩트 정리는 바로 이루어져야 합니다.

극한 테스트

https://github.com/rescript-lang/build-benchmark 를 사용하여 1만개의 파일(디렉터리 2개, 파일 5천개, 처음 5000개는 의존성이 없고 마지막 5000개는 이전 디렉터리의 파일에 대한 10개의 의존성을 가집니다.)로 구성된 대규모 프로젝트에서 rescript.exe 를 2015 early 맥북 프로 레티나(3.1 GHz Intel Core i7)에서 스트레스 테스트하였습니다.

• 1만개의 No-op 빌드 : 800ms (1만개 파일의 mtimes를 확인하는데 필요한 최소 시간)
• 클린 빌드 : 3분 이내
• 증분 빌드 : 파일의 의존성에 따라 다릅니다. 의존성이 없는 경우 1s

안정성

감시자는 또한 rescript.exe를 호출하는 가벼운 파일 감시자 입니다. 우리는 자식을 관리하는 데몬 프로세스를 좋아히자 않습니다.

증분성 및 정확성

리스크립트는 매번 실행하는데 몇 초 걸리지 않습니다. 빌드 성능의 대부분은 몇 개 파일이 변경되었을 때 이전에 빌드된 프로젝트를 다시 빌드하는 증분 빌드에서 나옵니다.

간단하게, 컴파일러와 빌드 시스템 아키텍처 덕분에 필요한 것만 빌드 할 수 있습니다. 예를 들어 MyFile.res 가 변경되지 않으면 다시 컴파일하지 않습니다. 자바스크립트와 같은 언어로 이러한 점진주의를 에뮬레이션 할 수 있지만 안타깝게도 정확성의 정도는 낮습니다. 예를 들어 자바스크립트의 이름을 바꾸거나 이동하면 감시자가 혼란스러워 "새" 파일을 선택하지 않거나 올바르게 정리하지 못하기 때문에 빌드를 정리하고 다시 시작해야합니다. 이는 목적을 달성하지 못한 것 입니다.

자바스크립트 생태계에서 오래된 빌드를 떠나보내세요!

증분 빌드 속도 향상

리스크립트는 인터페이스 파일 (.resi) (또는 모듈 시그니처) 개념을 사용합니다. 필요한 것만 노출하면 자연스레 증분 빌드 속도가 향상됩니다. 예를 들어 .resi 파일이 변경된 부분을 노출하지 않는 .res 파일을 변경하면 다시 빌드해야하는 의존 파일의 양이 줄어듭니다.

프로그래밍 방식 사용

안타깝게도, 자바스크립트 빌드 시스템은 현재의 자바스크립트 프로젝트를 빌드하는데 있어 병목이 됩니다. 나머지 빌드가 몇 초 또는 문자 그대로 몇 분이면 빌드의 일부를 엄청나게 빠르게 유지하는 것은 중요하지 않습니다. 다음은 몇가지 제안입니다:

• 리스크립트로 더 많은 파일을 변경하세요 =). 자바스크립트 파이프라인을 통과하는 파일이 줄어들면 크게 도움이 됩니다.
• 라이브러리, 구문 변환 (예: 비공식적으로 지원되고 있는 PPX), 빌드 단계의 로더 등 더 많은 의존성을 가져오는 것을 주의해야합니다. 이러한 대부분의 수정과 빌드 경험은 이들이 제공하는 API의 이점보다 비중이 클 수 있습니다.

핫 리로딩

핫 리로딩은 개발 서버를 유지한채로 현재 실행중인 브라우저 페이지로 바로 변경 사항을 파이프 하는 방식을 이용해 변경사항을 수신하는 것을 말합니다. 이는 특정 프레임워크에서 작업하는 동안 비교적 빠른 반복 워크플로우를 제공합니다.

그러나 핫 리로딩은 본질적으로 취약하며 가끔 불일치(잘못된 상태, 잘못된 평가 등)가 발생하고 무거운 개발서버 설정과 구성이 주는 이점보다 번거롭게 느껴집니다. 우리는 일반적으로 주의와 안정성 측면에서 오류를 범하여, 아직은 핫 리로딩을 내장하지 않기로 했습니다.

참고 : 자바스크립트 빌드 파이프라인에서 제공하는 핫 리로딩 기능을 계속 사용할 수 있습니다.