PHPとPythonとRubyの連想配列のデータ構造が同時期に同じ方針で性能改善されてた話 - hnwの日記
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
PHPとRubyとPythonのparserをいじめてみた - hnwの日記
下記のようなプログラムを与えると、PHPのparserが「無理っす」と言って死にます。 <?php !!!…（10000個くらい）…!!!true; $ php ./hoge.php PHP Parse error: memory exhausted in /Users/hanawa/hoge.php on line 2yaccによるparserはシフトと還元を繰り返しながら構文解析していきます。単項演算子について言えば、後置された表現が確定するまで還元できませんから、!が連続している間はシフトし続け、トークンをスタックに積み続ける必要があります。 このようにトークンを記録するためのスタックのサイズがPHPでは10000個しかありません。ですから、単項演算子を10000個ほど書くだけで簡単に死にます。他にも、「(」を10000個ほど連続して置くなどの嫌がらせでもPHPを死なせることができま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.av-jyo.com/2011-08/12-things-i-thought-when-starting-python-as-phper.html
