hnwの日記

PHPカンファレンス2017でphp-timecopをPECLに登録した話をしました

10月8日に開催されたPHPカンファレンス2017でLT発表をしました。以下が発表資料です。



PECLは登録までの敷居が高そうな印象があったので、以前は自作のPHP拡張を登録するなんて考えもしなかったのですが、やってみたら案外あっさり登録できた、という内容を紹介しました。詳細の手順については過去の記事「php-timecopをPECLに登録しました」に書きましたので、合わせてご確認ください。


また、PECLに登録すると自動的にRemi's RPM repositoryに入ること、さらに運が良ければ(?)Fedoraリポジトリにも入ることを紹介しました。これはRemiさんがPHPコアコミッターであるだけでなく、RedHat社員でもあるという事情もあると思いますが、何にせよやってみないとわからなかったことかなと思います。


余談ですが、PECLに登録してからissueが増えたという話を紹介しましたが、実は難しいissueが増えて私自身が捌き切れていない、というオチがあったりします。特に「PHP 7.2.0RC3でPHPの内部実装を変えたらphp-timecop動かなくなったからよろしくな」というissueの難易度が高く現在進行形で悩んでいるのですが、7.2.0リリースまでに解決できるよう頑張ります。

他のセッションについての感想など

今年のPHPカンファレンスも刺激をたくさんもらった集まりでした。個人的には内山さんの「OPcacheの最適化器の今」が興味深い内容でした。私もPHP 5.5の頃に似た内容の発表(「Zend OPcacheの速さの秘密を探る」)をしたことがあるのですが、当時は未実装だったconstant propagationやdead code eliminationといった最適化が実装されているというのは知りませんでした。


発表後に「われわれの普段書くコードの性能改善につながるのか?」というような質問があり、内山さんは「大抵の場合WebアプリケーションのボトルネックはDBアクセスなどになるのではないか、その意味ではOPcacheの最適化が実コードに与える影響は少ないと思われる、という回答をされていました。


大抵の現場で起きている問題を解決する特効薬にはならない、という意味では非常に正しい回答なのですが、現実のコードに対して意味のある最適化ではない、という風に捉えてしまった人もいたような気がします。しかし、特にconstant propagationは身近なコードでも有用な最適化です。たとえば下記のようなコードを書いたことがある人は多いのではないでしょうか。

<?php
$seconds_per_minute = 60;
$minutes_per_hour = 60;
$hours_per_day = 24;
$seconds_per_day = $seconds_per_minute * $minutes_per_hour * $hours_per_day


このようなコードは読みやすさの観点では意味がありますが、これまでのPHPでは性能面で僅かに不利になっていたわけです*1。これがきちんと最適化されるのであれば、安心して読みやすさ優先でコードを書けるわけですから、多くのPHPユーザーにとって嬉しい内容であるはずです。


それ以外の方々の発表も楽しかったですし、懇親会も2次会も非常に盛り上がった気がします。毎度おなじみの方も久々の方ともお会いでき、色々なお話が聞けて良かったです。php-timecop使ってます、という話も複数の方から聞けて非常に参考になりました。ありがとうございます。


最後になりますが、スタッフの皆様、今年もおつかれさまでした。これほどの規模になると運営は本当に大変だと思いますが、来年も期待しておりますのでよろしくお願いいたします。

*1:このコードを最適化するためには各行間へのジャンプ命令が存在しないことを知らないといけませんが、過去のPHPではそのような解析を行っていませんでした