Zend エンジンの最適化

PHP 5.4 のアップデートリストには、「Zend エンジンのパフォーマンスを向上させ、メモリ使用量を削減しました。

」という一文があります。

では、どのように改善されているのでしょうか?

不要なハッシュテーブルを避ける

PHP では、クラス属性/静的属性/定数はすべて Hashtable に格納されることがわかっています。以前は、クラスが属性/静的属性/定数を宣言していなくても、Zend エンジンがそれらに Hashtable を割り当てていました。

現在、このプロセスは最適化されており、要素がある場合にのみハッシュテーブルが割り当てられます。

これにより、一部の emalloc/efree 操作が回避され、メモリ使用量がいくらか削減されます。

四次最適化

PHP では、実際に実行されるのはオペコードです。1 つのオペコードには、result、left、right の 3 つの固定オペランドが含まれています。以前は、When there など、まったく使用されなかった場合でも、これら 3 つのオペランドのそれぞれに zval が含まれていました。右側のオペランドがない場合は、zval が右側のオペランドに割り当てられます。

現在、すべてのオペランドには zval が直接含まれなくなりますが、各 op 配列にはリテラル テーブルが含まれます。

また、znode もそれに応じて調整されました。

このようにして、以前の (32 ビット オペレーティング システム) オペコードが占有していたメモリ使用量も 72 バイトから現在の 28 バイトに削減できます。

さらに、文字列の場合、リテラル テーブルには文字列の事前に計算されたハッシュ値も保存され、実行時の複数の計算が回避されます。

リテラル文字列

C 言語と同様に、コード内のリテラル文字列は、実行期間全体を通じて固定セグメント (データ セグメント) に保存され、これらの文字列は定数文字列であり、変更したり解放したりすることはできません。

PHP もこの考え方を利用し、内部文字列の概念を提案しています。PHP コード内のリテラル文字列は一度割り当てられ、実行期間全体にわたって変更することはできません。

PHP が copy_zval や free zval などの操作を実行するとき、不必要な free や copy を避けるために内部文字列を特別に処理します。

このようにして、これらのリテラル文字列のハッシュ値が事前に計算され、ハッシュテーブルでの文字列比較 == とハッシュ計算に、この事前に計算されたハッシュ値が直接使用されるため、パフォーマンスが向上します。 🎜>

その他

もちろん、オペコードの最適化や不要なオペコードの削減など、最適化のポイントはたくさんありますので、ここでは詳しく説明しません

比較

以下は、PHP 開発チームの内部テストから得られたデータの一部です:

php-trunk	パッチが適用されました	改善
bench.php (秒)	4.31	3.49	19%
micro_bench.php (秒)	19.78	14.63	26%

いくつかの実際的なアプリケーション:

	php-trunk	パス済み	改善
ブログ (req/秒)	59.3	66.2	12%
drupal (要求/秒)	1073.9	1084.8	1%
FW (要求/秒)	105.3	111.8	6%
こんにちは (req/秒)	5362.5	5351.4	0%
qdig (要求/秒)	243.4	253.7	4%
typo3 (要求/秒)	355.3	382.6	8%
wordpress (要求/秒)	101.8	108.5	7%
xoops (要求/秒)	70.3	78.5	12%
スクラム (要求/秒)	86.5	104.2	20%

これらのデータから判断すると、パフォーマンスの向上は依然として明らかです..