本篇文章给大家介绍一分钟解读PHP是解释型还是编译型的？有一定的参考价值，有需要的朋友可以参考一下，希望对大家有所帮助。
编译型语言
- 使用专门的编译器（类似于Windows下的Visual Studio）、针对特定平台（操作系统）将某种高级语言源代码一次性“翻译”成该平台硬件执行的机器码（包括机器指令和操作数），并包装成该平台所能识别的可执行性程序（.exe）的格式，这个转换过程称为编译（Compile）。编译生成的可执行程序可以以脱离开发环境，在特定的平台上独立运行。有些程序在编译结束之后，还可能需要对其他编译好的目标代码进行链接，即组装两个以上的目标代码模块生成最终的可执行程序，通过这种方式实现低层次的代码复用。
- 编译型语言的代码是一次编译，循环使用。换句话说就是前人种树，后人乘凉。
- C、C++、Objective -C 等都属于编译型语言
解释型语言
- 在程序运行前将源程序预编译成中间语言，然后再由解释器执行中间语言
- 每次执行解释型语言的程序都需要进行一次编译，因此解释型语言的程序运行效率通常较低，而且它不能脱离解释器独立运行。
- C#、PHP、Python、Java等都是解释型语言。
OK，通过上面概念的简单了解，你可能对解释型、编译型语言有了一个大概的了解。既然两者平分天下，下面我们就来看一下两者各有什么优势吧。
编译型语言
优势
- 编译型语言最大的优势之一就是其执行速度。用C/C++编写的程序运行速度要比用Java编写的相同程序快30%-70%。
- 编译型程序比解释型程序消耗的内存更少。
劣势
- 不利的一面——编译器比解释器要难写得多
- 编译器在调试程序时提供不了多少帮助——有多少次在你的C语言代码中遇到一个“空指针异常”时，需要花费好几个小时来明确错误到底在代码中的什么位置。
- 可执行的编译型代码要比相同的解释型代码大许多。例如，C/C++的.exe文件要比同样功能的Java的.class文件大很多。
- 编译型程序是面向特定平台的因而是平台依赖的。
- 编译型程序不支持代码中实现安全性——例如，一个编译型的程序可以访问内存的任何区域，并且可以对你的PC做它想做的任何事情（大部分病毒是使用编译型语言编写的）
- 由于松散的安全性和平台依赖性，编译型语言不太适合开发因特网或者基于Web的应用。
解释型语言
优势
- 极佳的调试支持。一名PHP程序员只需要几分钟就可以定位并修复一个“空指针异常”，因为PHP运行环境不仅指明了异常的性质，而且给出了异常发生位置具体的行号和函数调用顺序（著名的堆栈跟踪信息）。这样的便利是编译型语言所无法提供的。
- 解释器比编译器容易实现
- 极佳的平台独立性
- 高度的安全性——这是互联网应用迫切需要的
- 中间语言代码的大小比编译型可执行代码小很多
劣势
- 占用更多的内存和CPU资源。这是由于，为了运行解释型语言编写的程序，相关的解释器必须首先运行。解释器是复杂的，智能的，大量消耗资源的程序并且它们会占用很多CPU周期和内存。
- 运行效率较编译型程序慢很多。解释器会做很多代码优化，运行时安全性检查；这些额外的步骤占用了更多的资源并进一步降低了应用的运行速度。
OK，通过上面的学习，相信大家对解释型语言与编译型语言有了大致的了解，而且PHP语言是解释型语言，而且解释PHP语言的解释器就是Zend引擎。
而且，根据两者的优劣势比较可以发现，编译型语言更适合做底层的操作，而解释型语言较多的用在了Web开发上。
再深入探讨下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：分发方式有call,switch和goto三种。哪种效率高呢？其实从上边解释已经可以初步了解了。switch和goto都是在zend_execute()这个函数中有对应的逻辑段，直接执行就可以了。而call是在zend_execute()这个函数中执行函数调用。明摆着：函数调用效率是最低的，调用一次就得压栈啊！所以效率上：call是最低的。对于switch和goto：比如要执行第三种命令的处理：switch还要先挨个判断是不是前两种，而goto根本不需要判断，直接跳到第三种命令的逻辑代码段去执行，这比switch少了顺序从上到下判断的损耗，所以：goto效率又比switch要高。 所以这三种分发方式总体而言：goto > switch > call
再说一下php这种编译和执行分离的弱点：
其实也不能算是弱点，虽然zend engine(php的虚拟机)将编译和执行严格分开，但是对于用户而言：就跟没分开一样，因为我每次执行一个php脚本请求都是要执行：编译->执行 这两个阶段。任何一个阶段都少不了。那么这一点我们可以拿来和c++这种编译型语言做一下对比： 同一个请求运行100遍
①对于c++，由于其前期只要编译一遍，编译好就不会再重复编译了，只需要执行就ok，所以其损耗为：
1次编译 + 100次执行
②对于php，其每次都要编译+执行，所以其损耗为：
100次编译 + 100次执行
显然:解释性语言从数量上来看：其消耗是比编译型语言多的多。说白了就是：php这种编译和执行相分离并不是真正的分离。而c++那种才算是真正的分离。
php也早就意识到这个问题了，于是就想了一个办法来解决这个问题：这个解决方案就是eAccelerator。主要思路如下：
当脚本第一次运行后，以某种方式保存编译后脚本（里边存放的是op_array），在我们规定的缓存有效时间内，当第二次运行该脚本时就不在进行重复性的编译工作，而是直接调用执行前面保存的编译后文件，大大提高了程序性能。
最后说一下php编译和执行分离的优点；
这个优点其实是针对程序员而言，对用户而言没什么。因为这两个阶段的分离，我们可以在这里做一些我们想做的事情。
比如想做文件加解密，你想把一些php脚本源码文件加密，让用户看不到源码。同时呢这个加密后的源码文件又可以被php虚拟机所解析和处理。当然：要实现这个前提是你先想好加解密算法并保证这个是可逆的过程。
现在你对php源码文件已经加密了，此时你需要定义一下这种加密文件的后缀，假设为:*.buaa。 那问题就是：我们怎么让php虚拟机可以处理这种后缀的文件呢？这就要用到上边所说的编译和执行相分离的过程了。
回想一下：编译阶段的输入是php源文件，输出是op_array。 ok,我们就在这个阶段做文章。主要思路为：首先在zend_compile_file()这个编译函数中：看一下输入文件的后缀：如果是正常的.php那就走正常逻辑，如果是*.buaa，那就先解密然后再走正常逻辑。。。
结论：
PHP是解释型语言，将PHP代码解释为opcode之后再交由Zend引擎执行。
使用APC缓存了opcode，减少了PHP解释为opcode这一步骤的时间。