C++ ときどき ごはん、わりとてぃーぶれいく☆

USAGI.NETWORKのなかのひとのブログ。主にC++。

PHPのメモリ消費量の簡単なベンチマーク、やっぱりダメポ

PHP memory allocation array benchmark ネタ

とりあえ図。

f:id:USAGI-WRP:20120303205825p:plain

ソース。

環境。

LH-MAIN /tmp/test% uname -a                     
Linux LH-MAIN 3.2.8-1-ARCH #1 SMP PREEMPT Mon Feb 27 21:51:46 CET 2012 x86_64 AMD Phenom(tm) II X4 940 Processor AuthenticAMD GNU/Linux
LH-MAIN /tmp/test% php --version          
PHP 5.3.10 with Suhosin-Patch (cli) (built: Feb  6 2012 19:18:12) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
LH-MAIN /tmp/test% cat /etc/php/php.ini | grep memory_limit
memory_limit = 2560M

何をしたのかと言うと、PHPで数値を保持すると思われる配列が消費するメモリ使用量について測定してみた。なぜそんな事をしたのかと言えば、php.iniで余り有ると思われる程に充分なメモリアロケートを許容しても大きめサイズの配列を扱うと何故かメモリ不足になって落ちたので。

結論を言葉で言うと、「この環境(PHP 5.3.1 @ Arch Linux (x86_64))では 212.9 [bytes/array-size] という恐ろしい事になっていた事が判った」となる。

ここで、単位[array-size]は、C++的に考えるなら[sizeof(uint_least32_t)相当]と読み替えても差し支えない。なぜなら結果からはarrayの要素として入れる値が0や1と言った様な小さな値であれ、10*pow(2,20)やそれに近い大きな値であれメモリ使用量の変化は常に一定と見做せるから。ちなみに、arrayの中に放り込んでいる値は [0 1 2 .. 10 * pow(2,20)] という数をC++的に言うところのstd::iotaしているだけで、この最大値は10,485,760。勿論、符号付きであるかに寄らず32bitの整数型で扱える範囲である、と言う訳。

つまり、この環境（PHPはバージョンやそれが実行されるOSによる挙動の変化が恐ろしくダイナミックである事はお忘れなく）では、高々32bitの整数1つをPHPがarrayに放り込むのに、なんと212.9[byte]ものメモリを必要としていたと考えて差し支えない。言うまでも無く、32bitの整数を扱うのに必要な情報量は当然高々32[bits]、4[bytes]である・ｗ・；

ちょっと意味が解らない。
PHPとは一体何なのか…。

ちなみに、環境変わればと言う訳でもののついでideoneさんにも投げてみた。

arrayを拡張する事102,400個ごとに凡そ7.08[MiB]増加している。つまり、 72.52 [bytes/array-size] という事になる…。

さっきの環境に比べると34%程のメモリ消費量と随分コンパクトな様だ。

…但し、繰り返すが32bitの整数値を保持するのに必要な情報量それ自体は高々32[bits]=4[bytes]である。「C++やCでプログラムを書いて、uint_least32_tをnewなりmallocしても、実際にはメタデータが必要じゃない！」という主張をしたい方があれば、「うん、そうだね。」と答えるし、std::unique_ptrやらstd::vectorやら使ったらどうのと言われれば、「まあ、そうだね。」と答えるが、それでもメモリ消費量がデータ本体の53倍に膨れ上がったり、18倍に膨れ上がったりはしない・ｗ・；

ここでふと思い出したのだけど、世の中には扱っている値が何であれ、内部的には全てを文字列として扱うとかゆーものが存在している事を昔どこかで聞いたか見たかした様な記憶が無い事も無い。

最初の環境と次の環境ではPHPの実行環境のアーキテクチャがx86_64(64-Bit)とi686(32-Bit)と大きな違い（この環境による違いは53倍とか18倍ではなくて3倍程度でしかないが・・・3倍・・・）があるし、さらにこれらの環境のPHPをビルドしたGCCのバージョンやオプションもも大きく違う可能性が高いわけで・・・、そこらへんと内部的に実際には文字列としてメモリアロケートされているって事を組み合わせるとこういう恐ろしい事に繋がるのかなぁ・・・。

さて、もうPHPの事なんて書きたくないので、もののついでに今日あったPHPのアレゲなネタを2つおまけでペタッ☆ミ

そのいち☆ミ

そのに☆ミ

うん、やっぱりPHPはダメだ・ｗ・；
少なくとも一回は爆発して大破壊された方がいいと思う。