PHP는 해석형입니까, 컴파일형입니까?

컴파일 언어
특정 플랫폼(운영체제)에 대해 특정 하드웨어가 실행하는 머신코드(머신 명령어, 오퍼랜드 포함)를 전용 컴파일러(Windows 아래의 Visual Studio와 유사)로 한 번에 '번역'하고, 그 플랫폼이 인식할 수 있는 실행성 프로그램(.exe)의 형식으로 포장하는 변환 과정을 컴파일(Compile)이라고 한다.컴파일을 통해 생성된 실행 프로그램은 헤어 환경에서 벗어나 특정 플랫폼에서 독립적으로 실행될 수 있다.어떤 프로그램들은 컴파일이 끝난 후에 다른 컴파일된 대상 코드를 링크해야 할 수도 있다. 즉, 두 개 이상의 대상 코드 모듈을 조립하여 최종 실행 가능한 프로그램을 생성함으로써 낮은 수준의 코드 다중화를 실현한다.
컴파일형 언어의 코드는 한 번에 컴파일되어 재활용된다.다시 말해 전인종(前人種)이 길러지고, 후손이 덕을 보는 것이다.
C, C++, Objective-C 등은 모두 컴파일형 언어이다

해석형 언어
프로그램을 실행하기 전에 소스 프로그램을 중간 언어로 미리 컴파일하고 인터프리터가 중간 언어를 실행합니다
해석형 언어의 프로그램을 실행할 때마다 한 번의 컴파일이 필요하기 때문에 해석형 언어의 프로그램 운영라인 효율은 일반적으로 낮으며 인터프리터로부터 분리되어 독립적으로 작동할 수 없다.
C#, PHP, 파이썬, 자바 등이 모두 해석형 언어다.
위의 개념의 간단한 이해를 통해 해석형, 컴파일형 언어에 대한 대략적인 이해가 있을 수 있습니다.양자가 천하를 균등하게 나눈 이상, 우리 두 사람이 각각 어떤 우세를 가지고 있는지 보자.
컴파일 언어
우세
컴파일형 언어의 가장 큰 장점 중 하나는 실행 속도다.C/C++로 작성된 프로그램은 자바로 작성된 같은 프로그램보다 30~70% 더 빠르게 실행된다.
컴파일형 프로그램은 해석형 프로그램보다 메모리를 적게 소모한다.
열세
불리한 점—컴파일러는 인터프리터보다 훨씬 더 쓰기 어렵다
컴파일러는 프로그램을 디버깅할 때 많은 도움을 줄 수 없습니다.몇 번이나 C언어 코드에서 '빈 포인터 이상'을 만났을 때, 몇 시간 동안 오류가 코드에서 어떤 위치에 있는지 밝혀내는 데 시간이 걸린다.
실행 가능한 컴파일형 코드는 같은 해석형 코드보다 크다많은. 예를 들어, C/C++의 .exe 파일이 같은 기능의 Java의 .class 파일보다 훨씬 큽니다.
컴파일러는 특정 플랫폼을 지향하는 까닭은 플랫폼 의존이다의。
컴파일러는 코드에서 보안을 지원하지 않습니다. 예:컴파일된 프로그램은 메모리의 모든 영역에 액세스할 수 있으며 PC에서 원하는 모든 것을 할 수 있습니다(대부분의 바이러스는 컴파일된 언어로 작성됩니다).
느슨한 보안과 플랫폼 의존성으로 인해 컴파일된 언어인터넷이나 웹 기반 응용 프로그램 개발에는 적합하지 않다.
해석형 언어
우세
훌륭한 디버깅 지원.PHP 프로그래머 한 명이 몇 분 만에 '빈 포인터 이상'을 찾아내고 복구할 수 있는 것은 PHP 작동 환경이 이상 성질뿐만 아니라 이상 발생 위치의 구체적인 행번호와 함수 호출 순서(유명한 스택 추적 정보)를 제시하기 때문이다.이러한 편리함은 컴파일러형 언어로는 제공할 수 없는 것이다.
인터프리터는 컴파일러보다 구현하기 쉽다
훌륭한 플랫폼 독립성
고도의 보안—인터넷 애플리케이션에 매우 필요한
중간 언어 코드의 크기가 컴파일형 실행 코드보다 훨씬 작다
열세
더 많은 메모리와 CPU 자원을 점유한다.해석형 언어로 작성된 프로그램을 실행하기 위해서는 해당 해석기가 먼저 작동해야 하기 때문이다.인터프리터는 복잡하고, 지능적이며, 자원을 많이 소비하는 프로그램이며, CPU 주기와 메모리를 많이 차지합니다.
실행 효율이 컴파일형 프로그램에 비해 훨씬 느리다.인터프리터는 많은 코드 최적화, 런타임 보안 검사를 수행할 것이다. 이러한 추가 단계는 더 많은 리소스를 차지하며 애플리케이션의 런타임을 더욱 감소시킨다.
위의 학습을 통해 해석형 언어와 컴파일형 언어에 대해 대략적으로 이해하셨으리라 생각되며, PHP 언어는 해석형 언어이며, PHP 언어를 해석하는 인터프리터가 Zend 엔진입니다.

또 양자의 장단점을 비교한 결과 컴파일형 언어는 하층 조작에 더 적합하고 해석형 언어는 웹 개발에 더 많이 사용되는 것으로 나타났다.

PHP의 집행 과정을 더 깊이 연구한다.

php의 컴파일과 실행은 분리되어 있다.많은 사람들이 c++도 그렇구나.근데 이런 php의 분리는 우리에게 많은 편의를 제공할 수 있습니다.리, 피할 수 없는 단점도 있다.
먼저 전체 과정을 말씀드리겠습니다.
①php는 컴파일 함수 zend_compile_file()을 호출하여 컴파일한다. 이 함수의 구체적인 구현은 어휘 분석(Lex 구현), 문법 분석(Yacc 구현)의 두 가지 주요 과정을 포함한다.이 함수를 실행하면:php 스크립트의 컴파일은 종료된다. 이 함수의 입력은 php 스크립트 파일, 출력은 op_array이다. 간단히 말해서 컴파일 과정은 스크립트를 하나의 php 가상 머신으로 해석하여 처리할 수 있는 명령으로, op_array는 이러한 명령으로 만들어진 array일 뿐이다.

②: 그 후 php 가상머신은 zend_execute()라는 함수를 호출하여 실행한다.이 함수의 입력은 바로 위의 컴파일 단계에서 생성된 op_array이며, 여기서 그는 각각의 명령을 해석하여 처리한다. op 명령은 모두 150여 개이기 때문에 이 150개 명령을 처리해야 한다.150가지 명령을 어떻게 처리하느냐는 흥미로운 질문이 나옵니다.우선 명령어마다 대응하는 프로세서가 있어 처리한다.따라서 가상 기회는 op_array 내의 각 명령의 유형에 따라 응답 프로세서에 분배되어 처리된다.

여기 두 가지 작은 문제가 있습니다. 1: 여기 있는 프로세서는 무엇입니까? 2:어떻게 나눠주나요?

이 두 문제를 풀려면 모두 배포 메커니즘에서 설명해야 한다: php 가상 머신이 명령을 배포하는 메커니즘은 세 가지이다: CALL, SWITCH, GOTO. 이 세 가지 유형이 있다. php 기본값은 CALL 방식, 즉 모든 opcode 프로세서를 함수로 정의하고 가상 머신을 호출하는 것이다. 이러한 방식은 전통적인 방식이며, 일반적으로 가장 안정적인 방식으로 간주된다. 반면 SWITCH 방식과 GOTO 방식은 switch와 goto를 통해 opcode를 해당 처리 로직(세그먼트)에 배포하여 실행한다.
그럼 이제 위의 두 가지 질문에 답하겠습니다.

1:프로세서는 사실op 명령어를 처리하는 논리입니다.함수의 형태로 존재할 수도 있고, 명령어 배포 방식에 따라 논리 세그먼트 방식으로 존재할 수도 있다.

2: 배포 방식 c올스위치 고토 세 가지다.어떤 것이 효율적일까? 사실은 위에서 설명한 것부터 알 수 있다.switch와 goto는 zend_exe입니다cute()라는 함수에 해당하는 논리 세그먼트가 있으니 그대로 실행하시면 됩니다.call은 zend_execute()라는 함수에서 함수 호출이 이루어진다.분명히:함수 호출 효율이 가장 낮습니다. 한번 호출하면 스택을 눌러야 합니다.그래서 효율은 :call이 가장 낮습니다.switch와 goto의 경우: 예를 들어 세 번째 명령을 실행하는 처리: switch는 하나둘씩 앞의 두 가지 명령인지 아닌지를 판단해야 하는데, goto는 아예 판단하지 않고 세 번째 명령의 논리 코드로 건너뛰어 실행한다. 이는 switch보다 위에서 아래로 순서대로 판단하는 손실이 적기 때문에 goto는 switch보다 효율이 높다. 따라서 이 세 가지 배포 방법은 다음과 같습니다: goto > switch > call
php는 기본적으로 call이기 때문에 php의 효능을 더 짜내고 싶다면 goto라는 명령어를 사용하면 된다.하지만 goto방식으로 실행속도는 높였지만 컴파일속도는 가장 느렸습니다.
php와 같은 컴파일 및 실행 분리의 약점을 다시 한 번 말씀드리겠습니다.

사실 약점이라고 할 순 없지만 engine(php의 가상 시스템)은 컴파일과 실행을 엄격히 구분하지만, 사용자에게는: 분리되지 않은 것과 같습니다. 왜냐하면 나는 매번 php 스크립트 요청을 실행하기 때문입니다: 컴파일 -> 실행 두 단계를 모두 수행합니다.어느 단계든 빠질 수 없다.c++와 같은 컴파일러 언어와의 비교를 할 수 있습니다. 같은 요청을 100번 실행합니다.

①c++의 경우, 그 전기는 컴파일되기만 하면 됩니다.한번 컴파일하면 컴파일이 반복되지 않는다. 실행만 하면 된다. 그래서 손실은 다음과 같다.

1차 컴파일 + 100차 컴파일행

②php에 대해 매번 컴파일 + 집좋다, 그러므로 그 손실은 다음과 같다.

100번 컴파일 + 100번차집행
명백히:해석적 언어는 양적으로 보면 컴파일 언어보다 소모량이 많다.php라는 컴파일과 실행의 상분리는 진정한 분리가 아니라는 얘기다.c++ 그런 게 진정한 분리다.



php도 이 문제를 오래 전부터 알고 있었기 때문에 이 문제를 해결할 수 있는 방법을 생각해 냈습니다. 바로 이 솔루션이 eAccelerator입니다.주요 사고방식은 다음과 같다.

스크립트가 처음 실행되었을 때 컴파일된 스크립트를 저장(안에 저장된 스크립트는 op_array)합니다. 지정한 캐시 유효 시간 동안 스크립트가 두 번째로 실행되었을 때 반복되지 않습니다.번역 작업은 앞에 저장된 컴파일을 직접 불러와 실행함으로써 프로그램 성능을 크게 향상시켰다.



이 방식은 php의 효율을 어느 정도 높였지만, 최종극의 방법은 아니고, 최종극은 컴파일러형 언어로 바꾸는 것이 좋습니다, 후후~~~

마지막으로 php 컴파일과 실행 분리의 장점을 말씀드리겠습니다.

이 장점은 사실 프로그래머들에게 있어서 그렇습니다.사용자 입장에서 보면 아무것도 아니다.이 두 단계가 분리돼 있기 때문에 우리가 하고 싶은 일을 여기서 할 수 있다.

예를 들어, 파일 암호를 해독하려면, p를 조금 더 넣어야 합니다.hp 스크립트는 소스 파일을 암호화해 사용자가 소스를 볼 수 없도록 한다.그리고 이 암호화된 소스 파일은 php 가상 머신에 의해 해석되고 처리될 수 있다.물론:이렇게 되기 전에제언은 먼저 암호 해독 알고리즘을 생각하고 이것이 가역적인 과정임을 보증하는 것이다.



현재 당신은 php 소스 파일에 대해 암호화되어 있습니다.이 때 암호화 파일의 접미사를 정의해야 합니다. *.buaa라고 가정합니다. 문제는 이런 접미사 텍스트를 어떻게 php 가상머신이 처리할 수 있느냐는 것이다.건은요? 이것은 위에서 말한 대로 컴파일하고 실행하는 상분리의 과정으로 쓰이게 됩니다.

돌이켜보면, 컴파일 단계의 입력은 php였다.원본 파일, 출력은 op_array입니다. 오케이,우리는 이 단계에서 글을 쓴다.주요 아이디어는 우선 zend_compile_file(zend_compile_file)이다.이 컴파일러 함수에서:입력 파일의 접미사를 보세요:정상.php라면 정상논리, *.buaa라면 복호하고 나서 정상논리...

하~그냥 쉬워요.물론:이 과정은 없다.어떤 말은 이렇게 간단하며, 또한 당신은 직접 zend_compile_file() 함수를 수정할 수 없으며, 마지막으로 자신이 확장하여 하나의 모듈을 처리한다.이 과정.
결론:
PHP는 해석형 언어로 PHP코드를 opcode로 해석한 뒤 Zend엔진이 실행한다.

APC를 사용하여 opcode를 캐싱하여 PHP가 opcode로 해석하는 단계를 줄였다.