摘要：是個(gè)巨大的資源庫，很多開發(fā)者都知道使用能自動(dòng)打印一份很好格式化的頁面源代碼的副本使用函數(shù)來預(yù)防潛在的敏感信息顯示給用戶。理想的錯(cuò)誤報(bào)告應(yīng)該被完全禁用在文件里。優(yōu)化語句，盡量少進(jìn)行。

Celebrate what you"ve accomplished, but raise the bar a little higher each time you succeed.

如果一個(gè)方法能被靜態(tài)，那就聲明他為靜態(tài)的，速度可提高1/4;

靜態(tài)方法在程序開始時(shí)生成內(nèi)存，但是多了會(huì)比實(shí)例方法多占用內(nèi)存，同時(shí)不可以自動(dòng)銷毀

echo的效率高于print,因?yàn)閑cho沒有返回值，print返回一個(gè)整型;

echo大字符串時(shí)，若沒有做調(diào)整就嚴(yán)重影響性能。

打開Apache的mod_deflate進(jìn)行壓縮 | ob_start先將內(nèi)容放進(jìn)緩沖區(qū)

在循環(huán)之前設(shè)置循環(huán)的最大次數(shù)，而非在在循環(huán)中;

銷毀變量去釋放內(nèi)存，特別是大的數(shù)組;

由于zend引擎，php的數(shù)組&對象特別占內(nèi)存

php數(shù)組的內(nèi)存利用率只有1/10

避免使用像__get, __set, __autoload等魔術(shù)方法;

如果__autoload不能高效的將類名與實(shí)際的磁盤文件（不僅僅是文件名）對應(yīng)起來，系統(tǒng)將做大量文件是否存在（include path中包含的路徑）的判斷，因而需要大量IO操作

所以需要一套清晰的將類名與實(shí)際磁盤文件映射的機(jī)制

requiere_once()比較耗資源;

因?yàn)閞equire_once需要判斷該文件是否被引用過

使用require/include方法避免

在includes和requires中使用絕對路徑，這樣在分析路徑花的時(shí)間更少;

如果包含相對路徑，php會(huì)在include_path里面遍歷查找文件

絕對路徑可以避免此類問題，因此解析操作系統(tǒng)路徑所需時(shí)間會(huì)少

如果你需要得到腳本執(zhí)行時(shí)的時(shí)間，$_SERVER["REQUEST_TIME"]優(yōu)于time();

前者是直接常量，后者需要執(zhí)行函數(shù)

能使用字符處理函數(shù)的，盡量用他們，因?yàn)樾矢哂谡齽t;

how grep work

str_replace字符替換比正則替換preg_replace快，但strtr比str_replace又快1/4;

str_replace會(huì)為期參數(shù)分配內(nèi)存

OPT: 用strpos先查找，看是否需要替換，如果需要再替換，效率差別在0.1%

如果一個(gè)函數(shù)既能接受數(shù)組又能接受簡單字符做為參數(shù)，例如字符替換，并且參數(shù)列表不是太長，可以考慮多用一些簡潔的替換語句，一次只替換一個(gè)字符，而不是接受數(shù)組做為查找和替換參數(shù)。大事化小，1+1>2;

用@掩蓋錯(cuò)誤會(huì)降低腳本運(yùn)行速度;

$row["id"]比$row[id]速度快7倍，建議養(yǎng)成數(shù)組鍵加引號的習(xí)慣;

錯(cuò)誤信息很有用;

在循環(huán)里別用函數(shù)，例如For($x=0; $x < count($array); $x), count()函數(shù)在外面先計(jì)算;

在方法里建立局部變量速度最快，幾乎和在方法里調(diào)用局部變量一樣快;

局部變量是存在棧中的，當(dāng)一個(gè)函數(shù)占用的棧空間不大，這部分內(nèi)存可能全部命中cache

如果一個(gè)函數(shù)里使用了全局和局部變量，當(dāng)兩段地址相差較大時(shí)，cpu cache需要來回切

建立一個(gè)全局變量要比局部變量要慢2倍;

建立一個(gè)對象屬性（類里面的變量）例如（$this->prop++）比局部變量要慢3倍;

建立一個(gè)未聲明的局部變量要比一個(gè)初始化的局部變量慢9-10倍;(NOTICE)

聲明一個(gè)未被任何一個(gè)函數(shù)使用過的全局變量也會(huì)使性能降低（和聲明相同數(shù)量的局部變量一樣），PHP可能去檢查這個(gè)全局變量是否存在;

方法的性能和在一個(gè)類里面定義的方法的數(shù)目沒有關(guān)系，因?yàn)槲姨砑?0個(gè)或多個(gè)方法到測試的類里面（這些方法在測試方法的前后）后性能沒什么差異;(the way of call method)

在子類里方法的性能優(yōu)于在基類中;

只調(diào)用一個(gè)參數(shù)并且函數(shù)體為空的函數(shù)運(yùn)行花費(fèi)的時(shí)間等于7-8次$localvar++運(yùn)算，而一個(gè)類似的方法（類里的函數(shù)）運(yùn)行等于大約15次$localvar++運(yùn)算;(Time consumption)

Surrounding your string by ‘ instead of ” will make things interpret a little faster since php looks for variables inside “…” but not inside ‘…’. Of course you can only do this when you don’t need to have variables in the string.(使用‘代替“會(huì)運(yùn)行的更快)

GOOD: $type = "mixed";

GOOD: $outp = "This is a ".$type." string";

當(dāng)輸出字符串時(shí)用逗號代替點(diǎn)分割更快些。注意：這只對echo起作用，這個(gè)函數(shù)能接受一些字符串作為參數(shù);

Based on the run method of echo

在apache服務(wù)器里一個(gè)php腳本頁面比相應(yīng)的HTML靜態(tài)頁面生成至少要多花2-10倍的時(shí)間，建議多用些靜態(tài)HTML頁面和少量的腳步;

除非你的安裝了緩存，不然你的php腳本每次被訪問都需要被重編譯。建議安裝個(gè)php緩存程序，這樣通過去除一些重復(fù)的編譯來很明顯的提高你20-100%的性能;

建議用memcached，高性能的分布式內(nèi)存對象緩存系統(tǒng)，提高動(dòng)態(tài)網(wǎng)絡(luò)應(yīng)用程序性能，減輕數(shù)據(jù)庫的負(fù)擔(dān);

對運(yùn)算碼(OP code)的緩存很有用，使得腳本不必為每個(gè)請求重新編譯

使用ip2long()和long2ip()函數(shù)把IP地址轉(zhuǎn)成整型存放進(jìn)數(shù)據(jù)庫而非字符型。這幾乎能降低1/4的存儲(chǔ)空間。同時(shí)可以很容易對地址進(jìn)行排序和快速查找;

Through the int instead of string could get a higher search and sorting

使用checkdnsrr()通過域名存在性來確認(rèn)部分email地址的有效性，這個(gè)內(nèi)置函數(shù)能保證每一個(gè)的域名對應(yīng)一個(gè)IP地址;

not available on Win

如果你在使用php5和mysql4.1以上的版本，考慮使用mysql_的改良函數(shù)mysqli_;

試著喜歡使用三元運(yùn)算符（？：）;

在你想在徹底重做你的項(xiàng)目前，看看PEAR有沒有你需要的。PEAR是個(gè)巨大的資源庫，很多php開發(fā)者都知道;

使用highlight_file()能自動(dòng)打印一份很好格式化的頁面源代碼的副本;

使用error_reporting(0)函數(shù)來預(yù)防潛在的敏感信息顯示給用戶。理想的錯(cuò)誤報(bào)告應(yīng)該被完全禁用在php.ini文件里。可是如果你在用一個(gè)共享的虛擬主機(jī)，php.ini你不能修改，那么你最好添加error_reporting(0)函數(shù)，放在每個(gè)腳本文件的第一行（或用require_once()來加載）這能有效的保護(hù)敏感的SQL查詢和路徑在出錯(cuò)時(shí)不被顯示;

使用 gzcompress() 和gzuncompress()對容量大的字符串進(jìn)行壓縮（解壓）再存進(jìn)（取出）數(shù)據(jù)庫時(shí)。這種內(nèi)置的函數(shù)使用gzip算法能壓縮到90%;

通過參數(shù)變量地址得引用來使一個(gè)函數(shù)有多個(gè)返回值。你可以在變量前加個(gè)“&”來表示按地址傳遞而非按值傳遞;

Like C

Fully understand “magic quotes” and the dangers of SQL injection. I’m hoping that most developers reading this are already familiar with SQL injection. However, I list it here because it’s absolutely critical to understand. If you’ve never heard the term before, spend the entire rest of the day googling and reading.(Removed as of PHP 5.4.0)

使用strlen()因?yàn)橐{(diào)用一些其他操作例如lowercase和hash表查詢所以速度不是太好，我們可以用isset()來實(shí)現(xiàn)相似的功能，isset()速度優(yōu)于strlen();

strlen只返回在zval結(jié)構(gòu)中存儲(chǔ)的已知字符串長度。

strlen調(diào)用經(jīng)過：字母小寫化，哈希查找，會(huì)跟隨被調(diào)用的函數(shù)一起執(zhí)行

eg: if(strlen($foo) < 5) instead of if(!isset($foo{5}))

When incrementing or decrementing the value of the variable $i++ happens to be a tad slower then ++$i. This is something PHP specific and does not apply to other languages, so don’t go modifying your C or Java code thinking it’ll suddenly become faster, it won’t. ++$i happens to be faster in PHP because instead of 4 opcodes used for $i++ you only need 3. Post incrementation actually causes in the creation of a temporary var that is then incremented. While pre-incrementation increases the original value directly. This is one of the optimization that opcode optimized like Zend’s PHP optimizer. It is a still a good idea to keep in mind since not all opcode optimizers perform this optimization and there are plenty of ISPs and servers running without an opcode optimizer.

++$i只使用3條指令（opcode），而$i++需要4條，

不要隨便復(fù)制預(yù)定義變量，會(huì)造成內(nèi)存的雙倍使用。

BAD : $name = $_POST["name"]; echo $name;

GOOD: echo $_POST["name"];

用file_get_contents代替file, open, feof, fgets。

盡量少進(jìn)行文件操作。

優(yōu)化SELECT SQL語句，盡量少進(jìn)行INSERT,UPDATE。

盡可能的使用PHP內(nèi)部函數(shù)。

循環(huán)內(nèi)部不要聲明變量，尤其是大變量：對象。

多維數(shù)組盡量不要循環(huán)嵌套賦值。

foreach效率高于while & for。

用$i += 1 代替 $i = $i + 1;

對global變量，用完就要unset掉。

如果在代碼中存在大量耗時(shí)的函數(shù)，可以考慮用C擴(kuò)展的方式實(shí)現(xiàn)他們。

打開apache的mod_deflate模塊，可以提高網(wǎng)頁的瀏覽速度。

echo的大變量問題

數(shù)據(jù)庫連接使用完畢即關(guān)掉，不要用長連接。

split比explode快

參考

http://www.cnblogs.com/glory-jzx/archive/2012/08/21/2649712.html