2560M何をしたのかと言うと、PHPで数値を保持すると思われる配列が消費するメモリ使用量について測定してみた。そんな事をしたのかと言えば、php.iniで余り有ると思われる程に充分なメモリアロケートを許容しても大きめサイズの配列を扱うと何故かメモリ不足になって落ちたので。いう恐ろしい事になっていた事が判った」となる。ここで、単位[array-size]は、C++的に考えるなら[sizeof(uint_least32_t)相当]と読み替えても差し支えない。結果からはarrayの要素として入れる値が0や1と言った様な小さな値であれ、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]である・w・;ちょっと意味が解らない。PHPとは一体何なのか...。ちなみに、環境変わればと言う訳でもののついでideoneさんにも投げてみた。i686arrayを拡張する事102,400個ごとに凡そ7.08[MiB]増加している。さっきの環境に比べると34%程のメモリ消費量と随分コンパクトな様だ。...但し、繰り返すが32bitの整数値を保持するのに必要な情報量それ自体は高々32[bits]=4[bytes]である。「C++やCでプログラムを書いて、uint_least32_tをnewなりmallocしても、実際にはメタデータが必要じゃない!」という主張をしたい方があれば、「うん、そうだね。」と答えるし、std::unique_ptrやらstd::vectorやら使ったらどうのと言われれば、「まあ、そうだね。」と答えるが、それでもメモリ消費量がデータ本体の53倍に膨れ上がったり、18倍に膨れ上がったりはしない・w・;ここでふと思い出したのだけど、世の中には扱っている値が何であれ、内部的には全てを文字列として扱うとかゆーものが存在している事を昔どこかで聞いたか見たかした様な記憶が無い事も無い。最初の環境と次の環境ではPHPの実行環境のアーキテクチャがx86_64(64-Bit)とi686(32-Bit)と大きな違い(この環境による違いは53倍とか18倍ではなくて3倍程度でしかないが・・・3倍・・・)があるし、さらにこれらの環境のPHPをビルドしたGCCのバージョンやオプションもも大きく違う可能性が高いわけで・・・、そこらへんと内部的に実際には文字列としてメモリアロケートされているって事を組み合わせるとこういう恐ろしい事に繋がるのかなぁ・・・。PHPの事なんて書きたくないので、もののついでに今日あったPHPのアレゲなネタを2つおまけでペタッ☆ミそのいち☆ミうん、やっぱりPHPはダメだ。え?ってなったのでもうPHPは忘れた方が幸せに長生きできると思いました。2012うん、やっぱりPHPはダメだ・w・;少なくとも一回は爆発して大破壊された方がいいと思う。Projectのなかのひとのブログ。