특정 블록 클로저 최적화가 왜 효과적일까요?

Question

2001 년의 매우 흥미로운 post에서 Allen Wirfs-Brock은 네이티브 스택을 수정하지 않고 블록 클로저를 구현하는 방법을 설명합니다.

그는 내가 이해하지 못하는 아이디어가 많아서 여기에 질문하는 것이 좋을 것이라고 생각했습니다. 그는 말합니다 :

블록의 수명 동안 절대 할당 할 수없는 변수 (예 : 메서드 및 블록을 둘러싼 인수)는 변수의 복사본이 클로저에 저장되어 있으면 환경에 배치 할 필요가 없습니다 이

를 만들 때 내가 충분히 이해 확실하지 않다 두 가지가 있습니다

1. 읽기 전용 변수의 두 복사본 환경으로 이동 변수를하는 것보다 빠릅니다을 사용하는 이유는 무엇입니까? 왜냐하면 둘러싸는 컨텍스트가 스택의 (원본) 변수에 액세스하는 것이 더 빠르기 때문입니까?
2. 두 변수를 동기화 된 상태로 유지하려면 어떻게해야합니까?

질문 1에 다른 이유가 있어야합니다. 그렇지 않으면 최적화를 구현하는 비용과 비교했을 때 이득이 표시되지 않습니다.

질문 2는 메소드가 아닌 블록에 할당 된 논인 인수를 취합니다. 스택에 저장된 oop가 블록 수명 기간 동안 변경되지 않은 이유는 무엇입니까?

Q2에 대한 답을 알고 있다고 생각합니다. 블록의 실행이 메서드의 실행과 얽힐 수 없기 때문에 (즉, 블록이 살아있는 동안), 둘러싸는 컨텍스트가 실행되지 않습니다. 그러나 블록이 살아있는 동안 스택을 임시로 수정할 수있는 방법이 없습니까?

Answer 1

@ aka.nice의 의견 덕분에 나는 클레멘트 베라 (Clent Bera) 지위의 두 가지 질문에 대한 답을 발견했습니다. 그 내용은 모두 즐겁고 명확합니다.

Q1의 경우 먼저 Allen의 말은 읽기 전용 변수의 복사본을 블록의 로컬 임시 인스턴스처럼 블록의 스택에 배치 할 수 있음을 의미합니다. 이렇게하는 이점은 모두 변수가 블록 외부에서 정의되고 그 내부에서 사용 된 변수가 블록에 기록되지 않는 경우에만 구체화됩니다. 이러한 상황에서 환경 어레이를 만들고 프롤로그 또는 에필로그를 방출하여 처리 할 필요가 없습니다.

스택 변수에 액세스하는 컴퓨터 코드 번째 [edi + offest]을 사용하면서 먼저 [ebp + offset]를 사용하여 위치를 다루기 때문에 한 환경에 액세스하는 데 필요한 하나에 해당 회 edi 환경 어레이를 가리 키도록 설정되어있는 (클레멘트의 표기법에서 tempVector). 따라서 모든 환경 변수 중 일부는 읽기 전용 인 경우에는 이득이 없습니다.

두 번째 질문은 클레멘트의 훌륭한 블로그에서도 대답합니다. 예, 블록의 스택에서 원래 변수와 사본 사이의 동기화를 끊을 수있는 또 다른 방법이 있습니다 : 디버거 (aka.nice가 말했듯이!) 프로그래머가 변수를 둘러싼 컨텍스트에서 수정하면 디버거에 조치를 감지하고 사본도 갱신하십시오. 프로그래머가 블록의 스택에있는 복사본을 수정하는 경우와 동일합니다.

여기에 질문을 올리게되어 기쁩니다. 내가 일명에서받은 도움.멋지고 클레멘트 베라 (Clement Bera), 어떤 사람들이 이메일로 저에게 보낸 의견은 제 이해를 증진시키는 데 많은 도움이되었습니다.

하나의 마지막 발언. Wirfs-Brock는 방법 컨텍스트의 구체화를 피하는 것이 필수적이라고 주장합니다. 나는 동의하는 경향이있다. 그러나 이러한 데이터 구조에 대한 많은 중요한 작업은 구체화가 경량 패턴을 따를 경우 더 잘 구현 될 수 있습니다. 보다 정확하게, 디버깅 할 때 네이티브 스택을 가리키는 "뷰어"로 이러한 컨텍스트를 모델링 할 수 있으며 두 인덱스를 사용하여 분석중인 활성화에 해당하는 부분을 구분할 수 있습니다. 이것은 효율적이고 깨끗하며 두 기술의 결합은 속도와 표현력을 동시에 가질 수 있기 때문에 세계 최고 수준을 이끌어냅니다. 스몰 토크는 놀랍습니다.