인라인 확장

Inline expansion

컴퓨팅에서 인라인 확장(inline expansion)은 함수 콜사이트를 호출된 함수의 본체로 대체하는 수동 또는 컴파일러 최적화입니다.인라인 확장은 매크로 확장과 비슷하지만 소스 코드(텍스트)를 변경하지 않고 컴파일 중에 발생하는 반면 매크로 확장은 컴파일러에 의해 처리되는 다른 텍스트가 됩니다.

인라인화는 중요한 최적화이지만 [1]성능에 복잡한 영향을 미칩니다.경험에 비추어 볼 때, 일부 인라이닝은 매우 적은 공간 비용으로 속도를 향상시키지만, 인라이닝된 코드가 너무 많은 명령 캐시를 소비하기 때문에 속도가 저하되고 상당한 공간도 소모됩니다.Peyton Jones & Marlow [2]1999에 1980년대와 1990년대의 인라이닝에 관한 소박한 학술 문헌에 대한 조사가 제공되었습니다.

개요

인라인 확장은 컴파일러가 호출되는 각 위치에 함수의 새 복사본을 배치하기 때문에 매크로 확장과 유사합니다.인라인 함수는 함수 호출 오버헤드가 저장되므로 일반 함수보다 약간 빠르게 실행되지만 메모리 패널티가 발생합니다.함수가 10회 삽입되면 함수의 복사본이 코드에 10개 삽입됩니다.따라서 inlining은 자주 호출되는 작은 함수에 가장 적합합니다.C++에서는 클래스 정의 내에서 정의된 경우 클래스의 멤버 함수는 기본적으로 인라인화됩니다(inline 키워드를 사용할 필요가 없습니다).그렇지 않은 경우 키워드가 필요합니다.컴파일러는 함수를 인라인화하려는 프로그래머의 시도를 무시할 수 있습니다. 주로 함수가 특히 큰 경우입니다.

인라인 확장은 함수를 호출할 때 시간 오버헤드(초과 시간)를 제거하기 위해 사용됩니다.일반적으로 자주 실행되는 기능에 사용됩니다.또한 매우 작은 기능에도 공간적 이점이 있으며, 다른 최적화를 위한 전환이 가능합니다.

인라인 함수가 없으면 컴파일러는 어떤 함수를 인라인화할지 결정합니다.프로그래머는 어떤 함수가 인라인되고 어떤 함수가 인라인되지 않은지를 거의 또는 전혀 제어할 수 없습니다.프로그래머에게 이 정도의 제어를 부여하면 인라인화할 함수를 선택할 때 애플리케이션 고유의 지식을 사용할 수 있습니다.

일반적으로 함수가 호출되면 브랜치 또는 호출 명령에 의해 제어가 정의로 넘어갑니다.인라이닝에서는 브랜치 또는 콜명령 없이 제어가 함수의 코드에 직접 드롭됩니다.

컴파일러는 보통 인라인 스테이트먼트를 실장합니다.루프 조건 및 루프 바디는 느린 평가가 필요합니다.이 속성은 루프 조건 및 루프 본문을 계산하는 코드가 인라인으로 입력되어 있을 때 충족됩니다.인라인 스테이트먼트의 또 다른 이유는 퍼포먼스에 대한 고려입니다.

기능적 프로그래밍 언어의 맥락에서 인라인 확장은 보통 베타 축소 변환 뒤에 이어집니다.

프로그래머는 소스 코드에 대한 일회성 작업으로 복사 및 붙여넣기 프로그래밍을 통해 함수를 수동으로 인라인화할 수 있습니다.단, 다른 인라인 제어 방법(아래 참조)은 프로그래머가 인라인 함수의 버그를 수정하면서 원래 함수 본체의 중복 버전을 간과할 때 발생하는 버그를 발생시키지 않기 때문에 바람직하다.

퍼포먼스에 미치는 영향

이 최적화의 직접적인 효과는 (기능 본체의 중복에 의한) 공간[a] 사용률의 악화를 희생하면서 (호출 오버헤드를 배제함으로써) 시간 성능을 향상시키는 것입니다.함수 본체의 중복에 의한 코드 확장은 단순한 [b]경우를 제외하고 지배적이며, 따라서 인라인 확장의 직접적인 효과는 공간을 희생하면서 시간을 단축하는 것이다.

그러나 인라인 확장의 주요 장점은 더 큰 함수로 [3]더 나은 최적화가 가능하기 때문에 함수 본문의 크기를 늘리기 때문에 더 많은 최적화와 향상된 스케줄링이 가능하다는 것입니다.인라인 확장이 속도에 미치는 궁극적인 영향은 복잡합니다.이는 최신 프로세서의 성능을 지배하는 메모리 시스템(주로 명령 캐시)의 성능에 대한 여러 가지 영향 때문입니다.특정 프로그램 및 캐시에 따라 특정 기능의 인라인화는 [1]성능을 높이거나 낮출 수 있습니다.

인라이닝의 영향은 추상화의 정도가 다르기 때문에 프로그래밍 언어와 프로그램에 따라 달라집니다.C와 포트란과 같은 하위 수준의 명령형 언어에서는 번호 크기에 가벼운 충격 층을 inlining 극도의 예 중 셀프, 한 컴파일러 55inlining 4의 개선 요인들 톱과 수가 때문에 그것은 일반적으로 10–20%속도 힘, 보다 더 추상적인 언어로 훨씬 더 중요할 수 있다..[2]

함수 호출을 배제함으로써 얻을 수 있는 직접적인 이점은 다음과 같습니다.

  • 호출 함수와 호출자 모두에서 함수 호출에 필요한 명령이 제거됩니다.스택 또는 레지스터에 인수를 배치하고 함수 호출 자체, 함수 프롤로그를 반환한 후 함수 epilogue, 리턴 스테이트먼트를 반환한 후 스택에서 인수를 삭제하고 reg를 복원합니다.(필요한 경우)
  • 인수를 전달하기 위해 레지스터가 필요하지 않기 때문에 레지스터 유출을 줄일 수 있습니다.
  • 이것에 의해, 참조에 의한 콜(또는 주소에 의한 콜, 또는 공유에 의한 콜)을 사용할 때에, 참조를 건네주고 나서 참조를 해제할 필요가 없어집니다.

그러나 인라인화의 주요 이점은 추가 최적화를 허용하는 것입니다.IPO(Interprocedure Optimization) 없이도 기능 경계를 넘나드는 최적화를 수행할 수 있습니다.인라이닝이 실행되면 확장된 기능 본체에서 추가적인 절차 내 최적화("글로벌 최적화")가 가능합니다.예를 들어 다음과 같습니다.

  • 인수로 전달되는 상수는 일치하는 파라미터의 모든 인스턴스로 전파되거나 (루프 불변 코드모션을 통해) 함수의 일부가 루프의 "호우아웃"될 수 있습니다.
  • 레지스터 할당은 더 큰 함수 본문에 걸쳐 수행할 수 있습니다.
  • 이스케이프 분석 및 테일 복제와 같은 고급 최적화는 더 큰 범위에서 수행될 수 있으며, 특히 이러한 최적화를 구현하는 컴파일러가 주로 절차 내 [4]분석에 의존하고 있는 경우 더욱 효과적입니다.

이것들은 인라인을 사용하지 않고 실행할 수 있지만, 훨씬 더 복잡한 컴파일러와 링커가 필요합니다(발신자와 착신자가 다른 컴파일 유닛에 있는 경우).

반대로, 어떤 경우 언어 사양은 프로그램이 프로시저가 인라인된 후 더 이상 만들 수 없는 절차에 대한 인수에 대한 추가 가정을 할 수 있도록 하여 일부 최적화를 방해할 수 있다.Glasgow Haskell 컴파일러 등 보다 스마트한 컴파일러에서는 이 정보가 추적되지만, 단순한 인라인에서는 이 정보가 손실됩니다.

메모리 시스템의 인라이닝의 또 다른 이점은 다음과 같습니다.

  • 브랜치를 제거하고 메모리 내에 근접하게 실행되는 코드를 유지함으로써 참조의 인접성(공간적 로컬리티 및 명령의 시퀀셜리티)을 향상시킴으로써 명령 캐시 성능을 향상시킵니다.이 값은 순차성을 목표로 하는 최적화보다 작지만 [5]유의합니다.

각 콜 사이트에서 기능 본체가 중복되기 때문에 인라이닝의 직접 비용은 코드 크기가 증가합니다.단, 이것이 항상 필요한 것은 아닙니다.즉, 함수 본문이 함수 콜의 크기(인수나 반환값 처리 포함)보다 작은 경우(발신자에서의 함수 본문), 예를 들어 사소한 액세스 방식이나 뮤테이터 방식(getters 및 setters) 또는 한 곳에서만 사용되는 함수(getters 및 setters)입니다.중복되지 않습니다.따라서 임베디드 시스템에서 흔히 볼 수 있듯이 코드 크기를 최적화하면 인라이닝이 최소화되거나 제거될 수 있습니다.

인라이닝은 (복제로 인해) 코드 확장으로 인해 명령 캐시 [6]성능이 저하되기 때문에 성능에도 비용이 듭니다.이는 확장 전에 프로그램의 작업 세트(또는 코드의 핫 섹션)가 메모리 계층의 한 수준(예: L1 캐시)에 적합하지만 확장 후에는 맞지 않기 때문에 해당 수준에서 캐시 누락이 자주 발생하는 경우에 가장 중요합니다.계층 레벨에 따라 퍼포먼스가 크게 다르기 때문에 퍼포먼스가 크게 저하됩니다.가장 높은 레벨에서는, 페이지 폴트가 증가하거나, 스레싱에 의해서 퍼포먼스가 저하되거나, 프로그램이 전혀 실행되지 않는 경우가 있습니다.이 마지막은 일반적인 데스크톱 및 서버 애플리케이션에서는 드물지만 코드 사이즈는 사용 가능한 메모리에 비해 작지만 임베디드 시스템 등 리소스가 제한된 환경에서는 문제가 될 수 있습니다.이 문제를 완화하기 위한 한 가지 방법은 기능을 보다 작은 핫인라인 패스(고속 패스)와 보다 큰 콜드비인라인 패스([6]슬로 패스)로 분할하는 것입니다.

성능 저하를 초래하는 인라이닝은 많은 곳에서 사용되는 대규모 기능에서 주로 문제가 되지만 인라이닝이 성능을 저하시키는 손익분기점은 판단하기 어렵고 일반적으로 정확한 부하에 의존하기 때문에 수동 최적화 또는 프로파일 가이드 최적화의 [7]영향을 받을 수 있습니다.이는 루프 언롤링과 같은 다른 코드 확장 최적화와 유사한 문제로 처리되는 명령의 수는 줄지만 캐시 성능 저하로 인해 성능이 저하될 수 있습니다.

캐시 퍼포먼스에 대한 인라이닝의 정확한 영향은 복잡합니다.캐시 크기가 작을 경우(확장 전 작업 세트보다 훨씬 작음) 시퀀셜리티가 증가하여 캐시 성능이 향상됩니다.인라이닝이 작업 세트를 확장하여 더 이상 캐시에 들어가지 않는 경우, 캐시 크기가 우세하고 캐시 성능이 저하됩니다.작업 세트보다 큰 캐시 크기의 경우 인라인화는 캐시 성능에 거의 영향을 미치지 않습니다.또한 로드 포워딩과 같은 캐시 설계의 변경은 캐시 [8]누락의 증가를 상쇄할 수 있습니다.

컴파일러 지원

컴파일러는 다양한 메커니즘을 사용하여 어떤 함수 호출을 인라인화할지 결정합니다.이러한 메커니즘에는 특정 함수에 대한 프로그래머의 수동 힌트와 명령줄 옵션을 통한 전체적인 제어가 포함됩니다.인라이닝은 많은 언어 컴파일러에 의해 자동으로 실행되며, 인라이닝이 유익한지에 대한 판단에 따라 다른 경우 컴파일러 디렉티브를 통해 수동으로 지정할 수 있습니다.일반적으로 다음과 같은 키워드 또는 컴파일러 디렉티브를 사용합니다.inline일반적으로 이것은 언어 및 컴파일러에 따라 다른 힌트의 힘으로 인라인잉을 필요로 하는 것이 아니라 인라인잉이 바람직하다는 것을 암시합니다.

일반적으로 컴파일러 개발자는 위의 성능 문제를 염두에 두고 컴파일러에 휴리스틱스를 포함시켜 대부분의 경우 성능을 악화시키는 것이 아니라 성능을 향상시키기 위해 어떤 함수를 인라인화할지 선택합니다.

실행

컴파일러가 특정 함수를 인라인화하기로 결정하면 인라인화 작업 자체는 보통 간단합니다.컴파일러가 서로 다른 언어의 코드에 걸쳐 함수를 인라인화하는지 여부에 따라 컴파일러는 높은 수준의 중간 표현(추상 구문 트리 등) 또는 낮은 수준의 중간 표현 중 하나를 인라인화할 수 있습니다.어느 경우든, 컴파일러는 단순히 인수를 계산하고, 함수의 인수에 대응하는 변수에 저장한 후, 호출 사이트에 함수의 본문을 삽입한다.

링커는 함수 인라인도 실행할 수 있습니다.링커는 함수를 인라인할 때 라이브러리 함수 등 소스를 사용할 수 없는 함수를 인라인화할 수 있습니다(링크 시간 최적화 참조).런타임 시스템은 인라인으로도 작동할 수 있습니다.런타임 인라인화는 동적 프로파일링 정보를 사용하여 Java [9]Hotspot 컴파일러와 같이 인라인화할 함수를 보다 효율적으로 결정할 수 있습니다.

다음으로 C 프로그래밍 언어로 소스레벨에서 "수동으로" 실행되는 인라인 확장의 간단한 예를 나타냅니다. 

인트 프리드(인트 x) {     한다면 (x == 0)         돌아가다 0;     또 다른         돌아가다 x - 1; }

인라이닝 전: 

인트 기능하다(인트 y)  {     돌아가다 프리드(y) + 프리드(0) + 프리드(y+1); }

인라이닝 후: 

인트 기능하다(인트 y)  {     인트 tmp;     한다면 (y   == 0) tmp  = 0; 또 다른 tmp  = y - 1;       /* (1) */     한다면 (0   == 0) tmp += 0; 또 다른 tmp += 0 - 1;       /* (2) */     한다면 (y+1 == 0) tmp += 0; 또 다른 tmp += (y + 1) - 1; /* (3) */     돌아가다 tmp; }

이것은 예에 불과하다는 점에 주의해 주세요.실제 C 어플리케이션에서는 파라미터화된 매크로나 인라인 함수 등의 인라인 언어 기능을 사용하여 컴파일러에 이 방법으로 코드를 변환하도록 지시하는 것이 좋습니다.다음 섹션에서는 이 코드를 최적화하는 방법을 보여 줍니다.

어셈블리 매크로 확장에 의한 인라인화

어셈블러 매크로는 일반적으로 단일 매크로 소스 문(파라미터 0 이상)에서 매크로 확장을 통해 일련의 명령을 인라인으로 생성할 수 있는 인라인 방식을 제공합니다.파라미터의 1개는 시퀀스를 포함하는 원타임 개별 서브루틴을 생성하는 옵션이며 대신 함수에 대한 인라인콜에 의해 처리됩니다.예:

From=array1에서 이동,TO=어레이2,인라인=없음

휴리스틱스

인라이닝을 위해 다양한 휴리스틱스가 탐구되어 왔다.통상, 인라인 알고리즘에는 일정한 코드 버젯(프로그램 사이즈의 증가가 허가)이 있어, 그 버젯을 넘지 않고, 가장 가치 있는 콜사이트를 인라인 하는 것을 목적으로 하고 있습니다.이러한 의미에서 많은 인라인 알고리즘은 보통 Knapsack [10]문제를 모델로 합니다.어떤 콜사이트가 더 가치 있는지를 판단하기 위해서는 인라인 알고리즘이 그 이점, 즉 예상되는 실행시간 단축을 추정해야 합니다.일반적으로,[11] 인라이너는 편익을 추정하기 위해 다른 코드 경로의 실행 빈도에 대한 프로파일링 정보를 사용합니다.

새로운 Just-in-Time 컴파일러는 프로파일링 정보 외에도 다음과 같은 [4]몇 가지 고급 휴리스틱스를 적용합니다.

  • 어떤 코드 패스가 실행 시간을 최대한 단축할 수 있는지 추측하고(인라이닝의 결과로 추가 컴파일러 최적화를 유효하게 함으로써), 이러한 패스의 인식상의 메리트를 높인다.
  • 컴파일 유닛의 크기와 이미 삽입된 코드의 양에 따라 인라인에 대한 비용 대비 편익 임계값을 적응적으로 조정합니다.
  • 서브루틴을 클러스터로 그룹화하고 단일 서브루틴 대신 클러스터 전체를 인라인화합니다.여기서 경험적 접근법은 클러스터의 적절한 서브셋만 삽입하면 아무것도 삽입하지 않는 것보다 성능이 저하되는 방법을 그룹화하여 클러스터를 추측합니다.

혜택들

인라인 확장 자체는 콜의 오버헤드를 없애기 때문에 최적화입니다만, 이노블로 하는 변환으로서 매우 중요합니다.즉, 컴파일러가 콜 사이트의 컨텍스트에서 함수 본문을 확장하면(종종 고정 상수일 수 있는 인수를 사용하여), 이전에는 불가능했던 다양한 변환을 수행할 수 있습니다.예를 들어 조건부 브랜치는 이 특정 콜사이트에서 항상 true 또는 false로 판명될 수 있습니다.그 결과 데드 코드 제거, 루프 불변 코드 모션 또는 유도 변수 제거가 활성화될 수 있습니다.

이전 섹션의 C 예에서는 최적화의 기회가 많이 있습니다.컴파일러는, 다음의 순서에 따릅니다.

  • 그tmp += 0(2) 및 (3)에 표시된 행의 문장은 아무것도 하지 않습니다.컴파일러가 삭제할 수 있습니다.
  • 조건0 == 0항상 참이기 때문에 컴파일러는 (2)로 표시된 행을 결과로 대체할 수 있습니다.tmp += 0(그것은 아무것도 하지 않는다)
  • 컴파일러는 조건을 다시 작성할 수 있습니다.y+1 == 0로.y == -1.
  • 컴파일러는 식을 줄일 수 있습니다.(y + 1) - 1로.y.
  • 표현들y그리고.y+1둘 다 0일 수 없습니다.이것에 의해, 컴파일러는 1개의 테스트를 생략할 수 있습니다.
  • 다음과 같은 문장에서if (y == 0) return y의 가치y몸에 알려져 있고, 인라인을 사용할 수 있습니다.

새로운 기능은 다음과 같습니다.

인트 기능하다(인트 y)  {     한다면 (y == 0)         돌아가다 0;     한다면 (y == -1)         돌아가다 -2;     돌아가다 2*y - 1; }

제한 사항

재귀로 인해 완전한 인라인 확장이 항상 가능한 것은 아닙니다.재귀 인라인 확장은 콜을 종료하지 않습니다.경계량을 확장하거나 특정 노드의 콜그래프와 브레이킹루프를 분석하는 등 다양한 솔루션이 있습니다(즉,[12] 재귀루프에서 일부 엣지를 확장하지 않는 것).매크로 확장에서도 같은 문제가 발생합니다.재귀 확장은 종료되지 않으며 일반적으로 (C 및 C++와 같이) 재귀 매크로를 금지함으로써 해결됩니다.

매크로와의 비교

기존에는 C 등의 언어에서는 파라미터화된 매크로를 사용하여 소스레벨에서 인라인 확장이 이루어졌습니다.C99에서 사용 가능한 진정한 인라인 함수를 사용하면 이 접근법에 비해 다음과 같은 이점이 있습니다.

  • C에서는 매크로 호출에서는 타입 체크를 실행하지 않습니다.또한 보통 함수 호출에서는 인수의 형식이 올바른지 체크조차 하지 않습니다.
  • C에서 매크로는 함수와 같은 의미의 return 키워드를 사용할 수 없습니다(매크로가 아닌 확장을 요구한 함수가 종료됩니다).즉, 매크로 내부에서 호출된 마지막 표현식의 결과가 아닌 어떤 것도 매크로가 반환할 수 없습니다.
  • C 매크로는 단순히 텍스트 치환만을 사용하기 때문에 인수와 조작 순서를 재평가하여 의도하지 않은 부작용과 비효율성을 초래할 수 있습니다.
  • 매크로내의 컴파일러 에러는, 프로그래머가 입력한 코드가 아니고, 확장 코드를 참조하고 있기 때문에, 이해하기 어려운 경우가 많습니다.따라서 일반적으로 인라인 코드의 디버깅 정보가 매크로 확장 코드보다 유용합니다.
  • 매크로를 사용하여 표현하기 어렵거나 불가능하거나 상당히 다른 구문을 사용하는 경우가 많습니다.인라인 함수는 일반 함수와 동일한 구문을 사용하여 쉽게 인라인 및 언인할 수 있습니다.

많은 컴파일러는 일부 재귀 [13]함수를 인라인으로 확장할 수도 있습니다.재귀 매크로는 일반적으로 불법입니다.

C++의 설계자인 Bjarne Stroustrup은 가능한 한 매크로를 피해야 한다고 강조하며 인라인 함수의 광범위한 사용을 지지합니다.

선택 방법

많은 컴파일러는 편리한 곳이라면 어디서든 적극적으로 인라인 함수를 인라인화합니다.실행 가능한 파일이 커질 수 있지만 메모리 용량이 CPU 속도보다 빠르게 증가함에 따라 공격적인 인라인화가 점점 더 바람직해지고 있습니다.인라인은 기능 언어와 객체 지향 프로그래밍 언어에서 중요한 최적화로, 일반적으로 작은 함수가 고전적인 최적화를 효과적으로 수행하기에 충분한 컨텍스트를 제공하기 위해 사용됩니다.

언어 지원

Java 및 기능언어를 포함한 많은 언어는 인라인 함수용 언어구성을 제공하지 않지만 컴파일러 또는 인터프리터가 적극적인 인라인 [4]확장을 수행하는 경우가 많습니다.다른 언어들은 일반적으로 컴파일러 지시어(pragmas)로 명시적인 힌트를 위한 구성을 제공합니다.

Ada 프로그래밍 언어에는 인라인 함수를 위한 플러그마가 있습니다.

Common Lisp의 함수는 에 의해 인라인으로 정의될 수 있습니다.inline선언:[14] 

 (외치다 (인라인 디스패치))  (삭제하다 디스패치 (x)    (펑콜      (얻다 (차 x) '오디오') x))

Haskell 컴파일러 GHC는 충분히 작은 함수 또는 값을 인라인화하려고 하지만 인라인화는 언어 플러그마를 [15]사용하여 명시적으로 기록될 수 있습니다.

키 기능 :: 내부 -> 스트링 -> (불, 이중) {-# INLINE 키_기능 #-}

C 및 C++

주요 기사:인라인 함수

C와 C++는inline키워드는 컴파일러의 지시어(인라이닝이 필요하지만 필수는 아님)로서 기능하며 가시성과 링크 동작도 변경합니다.표준 C 툴체인을 통해 기능을 인라인화하려면 가시성 변경이 필요합니다.이 툴체인은 개개의 파일(변환 유닛이 아닌) 컴파일 후에 링크됩니다.링커가 인라인 기능을 사용할 수 있도록 하려면 헤더에 이들 파일을 지정하고 마킹해야 합니다.inline(복수의 정의에 의한 애매함을 피하기 위해서).

「 」를 참조해 주세요.

메모들

  1. ^ 공간 사용량은 "명령어 수"이며 런타임 공간 사용량과 이진 파일 크기입니다.
  2. ^ 코드 사이즈는, 실제로는, 콜의 오버헤드가 함수의 본문보다 큰, 또는 중복이 발생하지 않는 일회용 함수에 대해서 축소됩니다.

레퍼런스

  1. ^ a b 첸 외 연구진 1993년
  2. ^ Chen et al. 1993, 3.4 기능 인라인 확장, 페이지 14.
  3. ^ a b c [1] Prokopec 등, Just-In-Time 컴파일러를 위한 최적화 기반 증분 인라인 대체 알고리즘, JVM용 Graal 컴파일러에 사용되는 인라이너에 대한 CGO'19 출판물
  4. ^ Chen et al. 1993, 3.4 기능 인라인 확장, 페이지 19-20.
  5. ^ a b Benjamin Poulain (August 8, 2013). "Unusual speed boost: size matters".
  6. ^ 예를 들어 Jikes RVM for Java의 웨이백 머신에서 Adaptive Optimization System Archived 2011-08-09를 참조하십시오.
  7. ^ Chen et al. 1993, 3.4 기능 인라인 확장, 페이지 24-26.
  8. ^ [2] Java용 Graal JIT 컴파일러에 사용되는 인라이너 설명
  9. ^ [3] Scheifler, 구조화된 프로그래밍 언어의 인라인 대체 분석
  10. ^ [4] 매튜 아놀드, 스티븐 핑크, 비벡 사르카, 피터 F.Sweeney, 인라인화를 위한 정적 및 프로파일 기반 휴리스틱스 비교연구
  11. ^ 페이톤 존스 & 말로 1999, 4. 종료 확인, 페이지 6-9.
  12. ^ 헨리 G. 베이커의 "재귀적인 서브루틴의 의미론 인라인화"
  13. ^ 공통 Lisp HyperSpec에서의 INLINE, NotINLINE 선언
  14. ^ 7.13.5.1. INLINE 플러그마 제7장 GHC 언어 기능

외부 링크

무료 사전인 Wiktionary에서 인라인 확장 또는 인라인 검색을 검색하십시오.