裸のPHPは実は結構速いが流行り筋のフレームワークは大概重たい

裸のPHPは実は結構速い。が、フレームワーク、特に最近一般的なMVCなものを挟むと数段重くそして遅くなる。

PHP MVC Framework Showdown: 7.1 Performance – Will Bowman – Medium

No framework: 7,094 requests per second, .34M memory.
Codeigniter 3: 2,245 requests per second, .38M memory.
Lumen 5.3: 1,543 requests per second, .63M memory.
Fuel 1.8: 1,033 requests per second, .60M memory.
Symfony 3.0: 551 requests per second, 1.52M memory.
Laravel 5.3: 331 requests per second, 1.53M memory
Zend 2.5: 291 requests per second, 1.34M memory

ワースト2: PHP開発元のZendが最遅で、次が大人気のLaravelなのは笑うところ。

より多数網羅したものは kenjis/php-framework-benchmark: PHP Framework Benchmark

karamawanu

PHP classにメンバ定義が無いのに代入できても嬉しくない場合が多いと思われる。


class foo {
  public $item_num;
}

$instance = new foo()
$instance->item_num = 10;

ありがちなプログラムの一節である。

class foo {
  public $item_num;
}

$instance = new foo()
$instance->num = 10;

これもままある。しかも動いてしまう。

厳密には、「処理を続行」する。そしてitem_numを期待してる箇所で空っぽであることにようやく発覚する。
stdclassなら判るものだが、class宣言したのだから代入制限してほしい。せめてwarningは欲しい。

OOPっぽいものを実装してはみたけど、感覚が「連想配列」のままなんだろうなあ、と忖度しないでもない。

class foo {
  public $item_num;
  protected $num;
}

$instance = new foo()
$instance->num = 10;

こうすればエラーは吐くようにはなる。が、num1への代入等は防げない。

マジックメソッドを使って、自前で判定を作ってる人は居た。
PHPのプロパティをStrictに定義する - Hack Your Design!

karamawanu

PHP 性能比較論 array_mapは無名関数を呼ぶしかないが foreach は処理を直に書けるため前者が遅いということになりがちだが、

ありがちな比較例

まったくの別件を調べようとしてググったら、下の記事が最古で見つかった。

厳密には同じ条件での比較とは言えない。

「1次元配列を加工するのにarray_map/foreachどっちで書いた方が速いか」という話ならまあこれで良い。

しかしforeachの場合は次のアドバンテージがある。

関数を呼んでない
配列$xsを直接潰してる。

2点目は忘れがちである。

他の記事も大体似たようなことになってる。

端的に言えば、人間が最適化しちゃってるので不公平な比較になってる。

処理内容を極力似せてみる。

この2点を踏まえて、サンプルを作り直して見ると。

<?php
$xs = array_pad(array(), 1000000, 1);

function f($x) { return $x + 100; }

$xs = array_map("f", $xs);

元との違いは、無名関数を辞めた。この1点

<?php
$xs = array_pad(array(), 1000000, 1);

function f ($x) { return $x + 100; };

foreach ($xs as &$x) {
  $x = f($x);
}

元との違いは、関数をわざわざ呼んだ。この1点。

小生の環境で測定してみる。

元記事とは環境が違うので、元のも比較のため全部載せる。

$ time php -q 2.php 

real	0m0.855s
user	0m0.829s
sys	0m0.023s
$ time php -q 3.php 

real	0m0.175s
user	0m0.161s
sys	0m0.013s
$ time php -q 2f.php 

real	0m0.530s
user	0m0.501s
sys	0m0.026s
$ time php -q 3f.php 

real	0m0.812s
user	0m0.787s
sys	0m0.020s

array_map版は無名関数を辞めたら2倍早く
forearch版は、内側で関数を呼んだら数倍遅く

何故か？ array_mapは、配列を入力して、配列を出力する、という処理に特化しているため、foreachに対してこの処理が浮いてるはず。

この辺りは何処かのPHPの高速化手法にも乗ってた気がするので、納得はできる。
結果的に順序関係が逆転して、array_mapの方が2倍程度は速いとは言えそうだ。

総論として、「関数を呼んで、1次元配列の全要素を加工する処理」としてのforeach/array_mapの比較としては、大体期待どおりの結果が得られたと言える。

karamawanu

FakerPHPのregexify関数の実装を読んでみる

偶然、fakerphpなるライブラリを知った。
今まで知らなかったのは、ランダムデータを使うタイプのテストはやらなかったため。
紹介してるページで最古はこのあたりか。

非常に気になったのが、regexifyという関数。
正規表現を受け付けて、それに合致する文字列を返すらしい。

まさか総当たりループとかしてないよな？とソースを眺めたらそんなことはなかった。
詳しくは下記のソースの通りなのだが。

既知の正規表現パターンから、preg_replace_callback 該当する生成関数を呼んでるだけだった。

実は regexify 内部関数からも呼ばれており、生成パターンの指定方法を汎用化しようとした名残だと思われる。

regexify は v1.21.0 で追加されたことがわかる。

ちなみに v1.21.0 のタグにはそんな記述はなかった....

karamawanu

PHP では rename 関数の失敗の原因が解らない件

PHPでローカルファイルをリネームするにはrenameを使うが、これはリネームに失敗してもfalseしか解らない。
オフィシャルドキュメントの通りだ。

PHP: rename - Manual

成功した場合に true を、失敗した場合に false を返します。

失敗するには例えば次のような理由が考えられる。

親ディレクトリが存在しない
ファイル名が長すぎる

しかもPHPではWarning扱いなのだ。

故に Warning メッセージとしては存在しており、ログに出力される。例えば次の通り

[Fri Mar 03 13:32:50.692503 2023] [:error] [pid 310452:tid 140355815065280] [client 192.168.0.18:57337] PHP Warning:  rename(***,***): File name too long in ********.php on line 127, referer: ****

ログに出力してる状態であれば、この文字列をPHPのプログラムの中で受け取る機能は存在する。

PHP: error_get_last - Manual https://www.php.net/manual/en/function.error-get-last.php

戻り値は連想配列になってる。["message"]の文字列には前述のログのような文字列がそのまま入ってるので、ここからエラーの文字列を改めて判定する必要がある。

ぇぇぇ....面倒なんだが.....

他の大抵のモダンな言語実装では、例外を吐いてくれる場合が多い

python3では os.OSError例外のcodeでerrnoが採れる。組み込み例外 — Python 3.11.2 ドキュメント

rubyではerrnoが戻るらしい。 File.rename (Ruby 3.2 リファレンスマニュアル)

nodejs fs.rename では Errorを吐くらしい File system | Node.js v19.7.0 Documentation