나는 바이슨의 JS 포트 인 jison을 사용하여 작은 언어의 JavaScript로 인터프리터를 작성했습니다. 언어는 표현과 조건을 평가하는 데 사용됩니다. 지금은 평가가 구문 분석과 혼합되어 있습니다.더 빠르고 깨끗하며 AST를 생성하고 반복하고 코드를 생성하는 것은 어느 것입니까?
나는 그것을 최적화하려고하는데 병목 현상은 렉서와 파서이다. 그래서 저는 손으로 그것을 파싱하고 런타임에만 평가하기로 결정했습니다.
더 빠르고 깨끗한 JS 코드를 생성하고 실행하거나 AST를 생성하고 런타임에 반복 실행하는 것이 문제입니다.
일반적으로 *는 항상 기계어에 가장 가까운 것을 생성하는 것이 더 빠릅니다. 귀하의 경우 자바 스크립트를 생성하는 것이 더 빠를 것입니다.
생성 된 자바 스크립트 코드는 기본 C/C++ 인터프리터 (일부 경우에는 컴퓨터 코드로 컴파일 된 경우도 있음)에 의해 직접 실행됩니다. 반대로 AST를 실행하기 위해 자바 스크립트에서 자신의 VM을 작성하면 VM - javascript의 추가 레이어에서 실행됩니다.
* 참고 : 인터프리터가 종종 네이티브 코드만큼 빨리 실행되는 경우가 있습니다. 인터프리터는 죽은 단순하기 때문에 예가된다. 단지 함수 포인터의 테이블 일 뿐이다.
컴파일 시간이 길면 순진한 방법으로 코딩 된 경우에도 인터프리터가 더 빠를 수 있습니다. 단점은 "compiletime + executetime (compiledprogram)"대 "interpreterime"입니다. 컴파일러를 만들 에너지가 있다면 상황에 따라 가장 자주 승리하는 것을 선택하십시오. –
@IraBaxter : 컴파일 시간은 한 번 발생합니다. 따라서 더 길더라도 승리합니다. 게다가, 그것이 해석 되든 안 됐든이 경우에 컴파일됩니다 (OP는 그가 AST로 컴파일 중임을 언급했습니다). 어려운 부분은 대서양 표준 검사를 받고 있습니다. AST에서 명령어를 생성하는 것은 쉽지 않습니다 (실제로는 실행 가능한 출력을 생성하지 않고 AST를 직접 해석 할 수있을만큼 빠릅니다). – slebetman
'eval' = 컴파일러를 비싸게 = 비싸다. –
컴파일 된 코드와 해석 된 코드가 더 빠른지 궁금해합니다. 컴파일 된 코드는 거의 항상 더 빠를 것이지만 해석 된 것보다 더 많은 두통을 유발할 수 있습니다. – Bubbles
@JanDvorak 글쎄요, 한 가지는 모든 노드가 하나씩 발생하기 때문에 시작 시간이 충분하다는 것입니다. 시작하기 전에'eval'을 호출하기 전에 런타임에 결과 함수를 실행합니다. –