저는 처음 C 언어와 같은 프로그래밍 언어를 만들려고합니다. 아마도 통역사가 될 것입니다. 그리고 나는 방금 첫 번째 단계 인 렉서를 만들었습니다.랭귀 싱 lexing : 한 번에 또는 개별적으로 문자열을 모두 lex하는 것이 더 좋습니까?
전체 소스 코드 스트림을 모두 하나씩 렉싱하여 지연 경로를 생각한 다음 파서가 데이터를 처리하도록했습니다.
나는 파서 모듈이 다른 토큰을 요구할 때 많은 다른 컴파일러와 인터프리터가 파싱하는 동안에 만 lex라는 것을 알아 차렸다.
소스 코드를 모두 한 번에 훑어보고 결과 토큰이나 렉스와 구문 분석 토큰을 개별적으로 구문 분석하는 것이 코드 성능 측면에서 더 빠릅니까?
"빠름"은 약간의 퍼지 단어입니다. 다양한 종류의 속도 (대기 시간, 절대 시작 완료 시간, 컴파일 속도, 실행 속도)가 있으며 언어 프런트 엔드 및 백엔드 구현 방법에 따라 두 방법 중 어느 쪽이 더 빠를 수 있습니다.
또한 빠를수록 항상 좋은 것은 아닙니다. 파서가 기술적으로 빠르지 만 너무 많은 메모리를 사용하면 충돌을 일으키거나 스와핑을 끝내면 다시 느려질 수 있습니다. 파서가 번개 속도는 빠르지 만 비효율적 인 코드를 생성하는 경우 사용자는 더 빠른 개발 속도를 지불하게됩니다. 실제 코드를 작성하고 프로파일 러에서 실행하여 실제로 더 나은 점을 알 수 있고 어떤 기준이 중요한지 생각해 내야합니다.
처음부터 모든 것을 토큰 화/렉싱한다는 것은 메모리 할당을 최적화하여 토큰 목록의 크기를 조정하는 시간을 단축 할 수 있음을 의미하지만, 파일 전체가 렉스되기 전에 작성되어야 함을 의미합니다 부분적으로 파싱 됨.
OTOH 필요한 경우 구문 분석을 수행하면 배열을 작은 단계로 더 자주 추가해야 할 수 있으므로 메모리 처벌을 지불해야합니다. 자바 스크립트와 같은 인터프리터 언어를 사용하는 경우이 런 스루에 실제로 사용되는 부분 만 구문 분석하면됩니다.
그래서 많은 내용은 언어의 세부 사항과 실행중인 하드웨어에 따라 다릅니다. 메모리가 거의없고 스왑이없는 임베디드 시스템에서 전체 프로그램 소스 코드가 메모리에 맞지 않을 수 있으므로 점차 lex를 선택할 수 밖에 없습니다. 귀하의 언어 구문에 많은 미리보기가 필요한 경우, 어쨌든 모든 것을 읽고 있기 때문에 점진적으로 렉싱하는 것이 도움이되지 않을 수도 있습니다 ...
아, 질문과 약간 관련이있을 수 있습니다 http://stackoverflow.com/questions/24306893/what-is-the-difference-between-compilation-and-interpretation/24308305#24308305 – uliwitness
내 타겟 하드웨어가 가능하면 임베디드 및 대형 시스템 모두에 적합해야합니다.내 언어가 정확히 "하나의 크기에 모두 들어 맞는"언어는 아니지만 언어로 OS 커널을 작성할 수있는 수준까지 저급 기능과 속도를 선호합니다. – Nergal
개발자 환경과 배포 플랫폼 간에는 차이가 있음에 유의하십시오. 컴파일러가 대부분의 경우 임베디드 시스템으로 만 크로스 컴파일하지만 괜찮 으면 좋습니다. 배포 플랫폼이 웹 서버이고 CGI를 인터프리터 스크립트로 구현하려는 언어는 서버 하드웨어가 무엇이든간에 실행해야합니다. 그럼에도 불구하고 실제적인 임베디드 하드웨어에서 그런 서버를 실행하려고하는 사람은 거의 없습니다. 지금 당장 급한 필요가없는 한, 버전 2.0을 위해 통역사를 최적화하지 않아도됩니다. – uliwitness
요청시 렉스보다 빠릅니다. 그렇지 않으면 거대한 대기 시간이 추가됩니다. 렉싱이 완료 될 때까지 구문 분석을 시작할 수 없습니다. – EJP
왜 그렇게 빠른가요? 나는이 이론을 이해하려고 노력하고있다. – Nergal
전반적으로 이것이 좋은 질문이라고 생각하지만 StackOverflow에는 적합하지 않습니다. StackOverflow는 특정 질문을 기대합니다. 이것은 렉싱이 발생할 수있는 모든 방법을 다루는 매우 광범위한 질문입니다. 그와 같이 나는 닫으려고합니다. –