php8編譯型

『壹』 php8、FPM及部分擴展編譯安裝

本著能懶則懶的原則，之前我都是寶塔、lnmp腳本等「一鍵」
再不濟也得來個 apt/yum install php
什麼？源碼 make install ？ 編譯參數一言難盡，勸退勸退...我只是想要個開發環境而已

沒關系！我來整理一下常用模塊以及參數！環境為 ubuntu/debian

檢查壓縮包的完整性，與官網 sha256比較

安裝以下包

官方的拓展分類
根據需要的模塊添加其後對應的參數

包含常用模塊，可以直接使用

編譯並安裝後
復制 php.ini 到默認目錄 /usr/local/lib/

檢查 php安裝是否正確

復制 fpm 配置文件、運行服務文件
www.conf php-fpm.conf php-fpm.service

修改 fpm 用戶和組，默認為nobody

修改服務文件，取消只讀 不然日誌不能讀寫無法啟動

設置自啟動並運行

本地起服務測試

No package 'libxml-2.0' found

No package 『sqlite3『 found

configure: WARNING: unrecognized options: –with-gd

No package 'zlib' found

No package 'libpng' found

No package 'oniguruma' found

No package 'libcurl' found

No package 'libsystemd' found

No package 'openssl' found

No package 'libzip' found

『貳』 怎樣編譯PHP文件

不需要編譯的，把PHP文件拷貝到你的網頁目錄裡面，在地址欄輸入：http://127.0.0.1/*.php就可以了

補充：
大家說得非常明白了，你自己寫的PHP程序，滑鼠雙擊就可以運行，不需要編譯。如果雙擊的時候問你用什麼打開，你就選擇你自己安裝的PHP.EXE文件。

多數情況PHP寫的程序是在網頁上用的，如果你也是寫的網頁程序，那就放在網頁文件夾下，用瀏覽器使用http://127.0.0.1/***.php來打開運行。

反正無需編譯，直接解釋運行。

『叄』 php是解釋性的語言，這里的解釋性是什麼意思和編譯有什麼區別

計算機不能直接理解高級語言，只能直接理解機器語言，所以必須要把高級語言翻譯成機器語言，計算機才能執行高級語言編寫的程序。 翻譯的方式有兩種，一個是編譯，一個是解釋。兩種方式只是翻譯的時間不同。編譯型語言寫的程序執行之前，需要一個專門的編譯過程，把程序編譯成為機器語言的文件，比如exe文件，以後要運行的話就不用重新翻譯了，直接使用編譯的結果就行了（exe文件），因為翻譯只做了一次，運行時不需要翻譯，所以編譯型語言的程序執行效率高，但也不能一概而論，部分解釋型語言的解釋器通過在運行時動態優化代碼，甚至能夠使解釋型語言的性能超過編譯型語言。 解釋則不同，解釋性語言的程序不需要編譯，省了道工序，解釋性語言在運行程序的時候才翻譯，比如解釋性basic語言，專門有一個解釋器能夠直接執行basic程序，每個語句都是執行的時候才翻譯。這樣解釋性語言每執行一次就要翻譯一次，效率比較低。解釋是一句一句的翻譯。

『肆』 PHP的性能探討和測試

1.緣起
關於PHP，很多人的直觀感覺是PHP是一種靈活的腳本語言，庫類豐富，使用簡單，安全，非常適合WEB開發，但性能低下。PHP的性能是否真的就如同大家的感覺一樣的差呢？本文就是圍繞這么一個話題來進陵搏行探討的。從源碼、應用場景、基準性能、對比分析等幾個方面深入分析PHP之性能問題，並通過真實的數據來說話。
2.從原理分析PHP性能
從原理分析PHP的性能，主要從以下幾個方面：內存管理、變數、函數、運行機制來進行分析。
2.1內存管理
類似Nginx的內存管理方式，PHP在內部也是基於內存池，並且引入內存池的生命周期概念。在內存池方面，PHP對PHP腳本和擴展的所有內存相關操作都進行了託管。對大內存和小內存的管理採用了不同的實現方式和優化，具體可以參考以下文檔：
2.2變數
總所周知，PHP是一種弱變數類型的語言，所以在PHP內部，所有的PHP變數都對應成一種類型Zval，其中具體定義如下：
在變數方面，PHP做了大量的優化工作，比如說Reference counting和 on writer機制。這樣能夠保證內存使用上的優化，並且減少內存拷貝次數（請參考
2.3函數
在PHP內部，所有的PHP函數都回轉化成內部的一個函數指針。比如說擴展中函數
ZEND_FUNCTION(my_function);//類似functionmy_function(){}
在內部展開後就會是一個函數
voidzif_my_function(INTERNAL_FUNCTION_PARAMETERS);
voidzif_my_function(intht,
zval*return_value,
zval*this_ptr,
intreturn_value_used,
zend_executor_globals*executor_globals);
從這個角度來看，PHP函數在內部也是對應一個函數指針。
2.4運行機制
在話說PHP性能的時候，很多人都會說「C/C++是編譯型，JAVA是半編譯型，PHP是解釋型」。也就是說PHP是先動態解析再代碼運行的，所以從這個角度來看，PHP性能必然很差。
的確，從PHP腳本運行來輸出，的確是一個動態解析再代碼運行的過程。具體來說，PHP腳本的運行機制如下圖所示：
PHP的運行階段也分成三個階段：
Parse。語法分析階段。
Compile。編譯產出opcode中間碼。
Execute。運行，動態運行進行輸出。
所以說，在PHP內部，本身也是存在編譯的過程。並且據此產生了大量的opcode cache工具，比如說apc、eacc、xcache等等。這些opcode cache在生產環境基本上在標配。基於opcode cache，能到做到「PHP腳本編譯一次，多次運行」的效果。從這點上，PHP就和JAVA的半編譯機制非常類似。
所以，從運行機制上來看，PHP的運行模式和JAVA是非常類似的，都是先產生中間碼，然後運行在不同虛擬機上。
2.5動態運行
從上面的幾個分析來看，PHP在內存管理、變數、函數、運行機制等幾個方面都做了大量的工作，所以從原理來看，PHP不應該存在性能尺御祥問題，性能至少也應該和Java比較接近。
這個時候就不得不談PHP動態語言的特性所帶來的性能問題了，由於PHP是動態運行時，所以所有的變數、函數、對象調用、作用域實現等等都是在執行階段中才確定的。這個從根本上決定了PHP性能中很難改變的一些東西：在C/C++等拆蔽能夠在靜態編譯階段確定的變數、函數，在PHP中需要在動態運行中確定，也就決定了PHP中間碼不能直接運行而需要運行在Zend Engine上。
說到PHP變數的具體實現，又不得不說一個東西了：Hashtable。Hashtable可以說在PHP靈魂之一，在PHP內部廣泛用到，包含變數符號棧、函數符號棧等等都是基於hashtable的。
以PHP變數為例來說明下PHP的動態運行特點，比如說代碼：
?php
$var=「hello,」;
?
該代碼的執行結果就是在變數符號棧（是一個hashtable）中新增一個項
當要使用到該變數時候，就去變數符合棧中去查找（也就是變數調用對出了一個hash查找的過程）。
同樣對於函數調用也基本上類似有一個函數符號棧（hashtable）。
其實關於動態運行的變數查找特點，在PHP的運行機制中也能看出一些。PHP代碼通過解釋、編譯後的流程下圖：
從上圖可以看出，PHP代碼在compile之後，產出的了類符號表、函數符號表、和OPCODE。在真正執行的時候，zend Engine會根據op code去對應的符號表中進行查找，處理。
從某種程度上，在這種問題的上，很難找到解決方案。因為這是由於PHP語言的動態特性所決定的。但是在國內外也有不少的人在尋找解決方案。因為通過這樣，能夠從根本上完全的優化PHP。典型的列子有facebook的hiphop。
2.6結論
從上面分析來看，在基礎的內存管理、變數、函數、運行機制方面，PHP本身並不會存在明顯的性能差異，但由於PHP的動態運行特性，決定了PHP和其他的編譯型語言相比，所有的變數查找、函數運行等等都會多一些hash查找的CPU開銷和額外的內存開銷，至於這種開銷具體有多大，可以通過後續的基準性能和對比分析得出。
因此，也可以大體看出PHP不太適合的一些場景：大量計算性任務、大數據量的運算、內存要求很嚴格的應用場景。如果要實現這些功能，也建議通過擴展的方式實現，然後再提供鉤子函數給PHP調用。這樣可以減低內部計算的變數、函數等系列開銷。
3.基準性能
對於PHP基準性能，目前缺少標準的數據。大多數同學都存在感性的認識，有人認為800QPS就是PHP的極限了。此外，對於框架的性能和框架對性能的影響很沒有響應的權威數字。
本章節的目的是給出一個基準的參考性能指標，通過數據給大家一個直觀的了解。
具體的基準性能有以下幾個方面：
1.裸PHP性能。完成基本的功能。
2.裸框架的性能。只做最簡單的路由分發，只走通核心功能。
3.標准模塊的基準性能。所謂標准模塊的基準性能，是指一個具有完整服務模塊功能的基準性能。
3.1環境說明
測試環境：
Uname -aPnux db-forum-test17.db01..com 2.6.9_5-7-0-0 #1 SMP Wed Aug 12
17:35:51 CST 2009 x86_64 x86_64 x86_64 GNU/Pnux
Red Hat Enterprise Pnux AS release 4 (Nahant Update 3)
8 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
軟體相關：
Nginx：nginx version: nginx/0.8.54 built by gcc 3.4.5 20051201 (Red Hat 3.4.5-2)
Php5：（採用php-fpm）
PHP 5.2.8 (cP) (built: Mar 6 2011 17:16:18)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
bingo2：
PHP框架。
其他說明：
目標機器的部署方式：nginx-php-fpm-php腳本。
測試壓力機器和目標機器獨立部署。
3.2裸PHP性能
最簡單的PHP腳本。
?php
require_once『./actions/indexAction.php』;
$objAction=newindexAction();
$objAction-init();
$objAction-execute();
?
Acitons/indexAction.php裡面的代碼如下
?php
classindexAction
{
pubPcfunctionexecute()
{
echo『hello,world!』;
}
}
?
通過壓力工具測試結果如下：
3.3裸PHP框架性能
為了和3.2的對比，基於bingo2框架實現了類似的功能。代碼如下
?php
require_once『Bingo/Controller/Front.php』;
$objFrontController=Bingo_Controller_Front::getInstance(array(『actionDir』=『./actions』,));
$objFrontController-dispatch();
壓力測試結果如下：
從該測試結果可以看出：框架雖然有一定的消耗，但對整體的性能來說影響是非常小的。
3.4標准PHP模塊的基準性能
所謂標准PHP模塊，是指一個PHP模塊所必須要具體的基本功能：
路由分發。
自動載入。
LOG初始化Notice日誌列印。所以的UI請求都一條標準的日誌。
錯誤處理。
時間校正。
自動計算每個階段耗時開銷。
編碼識別編碼轉化。
標准配置文件的解析和調用
採用bingo2的代碼自動生成工具產生標準的測試PHP模塊：test。
測試結果如下：
3.5結論
從測試數據的結論來看，PHP本身的性能還是可以的。基準性能完全能夠達到幾千甚至上W的QPS。至於為什麼在大多數的PHP模塊中表現不佳，其實這個時候更應該去找出系統的瓶頸點，而是簡單的說OK，PHP不行，那我們換C來搞吧。（下一個章節，會通過一些例子來對比，採用C來處理不見得有特別的優勢）
通過基準數據，可以得出以下幾個具體的結論：
1.PHP本身性能也很不錯。簡單功能下能夠達到5000QPS，極限也能過W。
2.PHP框架本身對性能影響非常有限。尤其是在有一定業務邏輯和數據交互的情況下，幾乎可以忽略。
3.一個標準的PHP模塊，基準性能能夠達到2000QPS（80 cpu idle）。
4.對比分析
很多時候，大家發現PHP模塊性能不行的時候，就來一句「ok，我們採用C重寫吧」。在公司內，採用C/C++來寫業務邏輯模塊的現象到處都有，在前幾年甚至幾乎全部都是採用C來寫。那時候大家寫的真是一個痛苦：調試難、敏捷不要談。

『伍』 編譯型語言和解釋型語言各自的優缺點是什麼

一、編譯型語言

優點：運行速度快，代碼效率高，編譯後的程序不可修改，保密性較好。

缺點：代碼需要經過編譯方可運行，可移植性差，只能在兼容的操作系統上運行 。

二、解釋型語言

優點：可移植性較好，只要有解釋環境，可在不同的操作系統上運行。

缺點：運行需要解釋環境，運行起來比編譯的要慢，佔用資源也要多一些，代碼效率低，代碼修改後就可運行，不需要編譯過程。

(5)php8編譯型擴展閱讀：

編譯型語言：程序在執行之前需要一個專門的編譯過程，把程序編譯成 為機器語言的文件，運行時不需要重新翻譯，直接使用編譯的結果就行了。程序執行效率高，依賴編譯器，跨平台性差些。如C、C++、Delphi等。而相對的，解釋性語言編寫的程序不進行預先編譯，以文本方式存儲程序代碼。在發布程序時，看起來省了道編譯工序。但是在運行程序的時候，解釋性語言必須先解釋再運行。

『陸』 PHP8新特性示例

命名參數 :就是具名參數，在調用函數的時候，可以指定參數名稱，指定參數名稱後，參數順序可以不安裝原函數參數順序傳

示例:

註解 ：註解可以將類定義成一個一個低耦合，高內聚的元數據類。在使用的時候通過註解靈活引入，反射註解類實例的時候達到調用的目的。註解類只有在被實例化的時候才會調用

示例

示例：

解釋 ：在不確定參數類型的場景下，可以使用.

示例：

解釋：和 switch case 差不多，但是嚴格要求 === 匹配

示例：

解釋：簡化了 is_null 判斷

示例：

考慮到 PHP 動態語言類型的特性，現在很多情況下，聯合類型都是很有用的。聯合類型是兩個或者多個類型的集合，表示可以使用其中任何一個類型。

請注意，聯合類型中不包含 void ，因為 void 表示的含義是 「根本沒有返回值」。 另外，可以使用 |null 或者現有的 ? 表示法來表示包含 nullable 的聯合體 ：

JIT — just in time — 編譯器雖然不總是在 Web 請求的上下文中，但是有望顯著地提高性能。目前還沒有完成任何准確的基準測試，但是肯定會到來。

屬性在其他語言中通常被稱為 註解 ，提供一種在無需解析文檔塊的情況下將元數據添加到類中的方法。

盡管已經可以返回 self，但是 static 直到 PHP 8 才是有效地返回類型 。考慮到 PHP 具有動態類型的性質，此功能對於許多開發人員將非常有用。

有人可能將其稱為必要的邪惡： mixed 類型讓許多人感覺十分混亂。然而，有一個很好的論據支持去實現它：缺少類型在 PHP 中會導致很多情況：

因為上述原因，添加 mixed 類型是一件很棒的事兒。 mixed 本身代表下列類型中的任一類型：

請注意，mixed 不僅僅可以用來作為返回類型，還可以用作參數和屬性類型。因為 mixed 類型已經包括了 null，因此 mixed 類型不可為空。下面的代碼會觸發致命錯誤：

已上是整理出來的新特性的變化,後續會繼續整理,PHP8的發布會讓PHP更上一層樓，相信PHP是世界上最好的語言！