Prezi日本語マニュアル

Preziは、無料で使える新しいタイプのプレゼン作成ツールです。PowerPointとは発想が異なり、プレゼン全体を一枚の大きな模造紙のように見立てて、その中を移動して行くようなイメージです。

最初にこのツールを見たのが2009年の1月でした。自分と仕事をしたことのある人は分かると思うのですが、ホワイトボードの前に陣取って全体像を描きながら説明するのがスタイルの自分には、非常にシックリくるツールです。当時は日本語が使えずに利用機会は無かったのですが、その後、限定的ではありますが日本語も使えるようになったので、徐々に利用が増えていきました。

単に「ちょっとカッコイイ感じのプレゼンが作れるツール」ではなく、ツールが思考の方を引っ張る好例ではないかと思っています。今自分はフリーで仕事をしていますが、以前のようにメンバーが居る立場であれば、ロジカルに物事を考える練習としてでも使わせてみたいななどと考えながらドキュメントを作りました。

興味を持ったら是非、ちょっと触ってあきらめずに、一本プレゼンを作ってみて下さい。
きっと、プレゼンの組み立てそのものが変わると思います。

No related posts.

Mandlin – QuickSilver風 ウェブナビゲーションツール

詳しい使い方はリンク先を見ていただくとして、YubNub+QuickSilverといった風の、様々な検索エンジンをキーボードベースで操ることのできるツールです。

自分が欲しくて作ったものなので使い勝手にはそれなりに満足していますが、なにしろ呼び出しにマウスを持ってクリックしなければいけないのが、なんとも残念な点で。せめてポップアップを開くAPIがあればショートカットキーもどきも出来なくは無いのですが… ポップアップではなく、コンテント・スクリプトでウインドウから描画してタブのコンテンツ内で表示させることも考えましたが、他人の家にあがりこむような感じにちょっと抵抗があったので、とりあえず由としておきます。

作成にあたって気づいた点など、徐々に リファレンス の方で更新していければと思っています。

Related posts:

1. [Chrome Extension] APIリファレンスの日本語訳

今回、勉強がてら公式のAPIドキュメントを日本語訳してみたので、公開しておきます。

Google Chrome Extension API 日本語リファレンス

馴染みのあるWeb技術ばかりで出来ているので、チュートリアルに沿ってひとつ作ってみれば、簡単に理解できました。あとはガイドを斜め読みしながら出来ることをおさえておき、作りながら必要にあわせてAPIリファレンスをひいてみる感じで。

まだ出来ることも限られていますが、プロセスが分かれていることもあり軽量で快適です。なかなかFFから移行できずにいたのが、おかげで最近はすっかりChromeメインで使っています。

というわけで幾つか作ってみたのですが、どうやら ギャラリーページのバグ でアップロードできず… いずれ問題が解決したら公開しようと思います。

作成途中で気づいたTipsなどもあるので、オリジナルのコンテンツも追加していく予定です。

Related posts:

1. [Chrome Extension] QuickSilver風の拡張機能

商業的利用やプロモーションのためにツイッターを利用する行為は許可されています。興味のあるユーザーとの間に、互いに価値のある関係を作るためにツイッターを利用する場合などです。ところが、自分のアカウントやサイトなどに注意を引くためだけに、ユーザーをフォローする行為はスパムとして扱われる可能性があります。まったく同じものを宣伝、または販売促進するためにたくさんのアカウントを登録することもスパムとして扱われる可能性があります。また本物ではない＠付きのつぶやきを投稿することや、検索結果に表示するためだけに投稿することもスパムとして扱われる可能性があります。さらに、つぶやきに関係のないリンクを貼ったり大勢のユーザーがあなたをブロックした場合などもスパムとして扱われる可能性があります。

ここにはハッシュタグに関する記述はありません。

もう一息、英語の方のヘルプフォーラムを調べてみたところ、それらしいものを見つけました。これによると、次のような行為がイエローカードに当たるようです。

• 同じ、或いは似たような呟きを繰り返す。
• 同じ、或いは似たようなリンクを繰り返し貼る。
• 同じ話題の単語、或いはハッシュタグを乱用する。
• 自動化された呟きや返信を送る。
• キーワードを基にした似たようなメッセージを送るボットやアプリケーションを使う。
• 複数のアカウントから似たようなメッセージを投稿する。
• 頻繁にフォロー/フォロー解除を繰り返す。

自分はハッキリは言われませんでしたが、ラグビー関連の話題を持ち出す際に慣例として使っていた #rugby が「同じハッシュタグの乱用」に当たったのではないかと思います。興味の無い人が読まなくて良いように呟きの先頭につけていたのですが、今後は止めにします。(アカウント分けた方が良いのかな…)
なお、「状況を改善して欲しい」とお願いしたところ、今朝から検索にヒットするようになりました。

どうやらTwitter検索八分は、完全にスパムアカウントとして凍結する前の「執行猶予」のようなもののようです。
「別に検索されなくてもいいや」としていると、場合によってはアカウント自体を停止されてしまうかもしれません。
気になる人は、エゴサーチで自分の発言がヒットするか試してみることをお勧めします。

No related posts.

「F5」でXHR通信結果が更新されない

通常、キャッシュが設定された外部ファイル取り込みは、その期限が来るまでは再通信されません。しかしブラウザをF5やCtrl+rなどで明示的にリロードした場合はその限りではなく、ファイルの再取得が行われるのが一般的です。
しかし、キャッシュ指定の条件によっては、XMLHttpRequestを用いた、いわゆるAjax通信時が発生しなくなってしまうとHttpWatchの記事で伝えられました。
これを検証するために、簡単なプログラムを作ってみます。

検証プログラムの説明

まずは、取り込まれるjsファイルを用意します。
サーバサイドで毎回ジェネレートされる、現在時刻を指定された要素に出力するだけのスクリプトです。

検証用スクリプト

呼び出す度に日時が更新されることが分かると思います。

そして必要なのはキャッシュコントロール。
パケット監視などが出来る人は見ていただけばわかるのですが、パラメータに応じて次のようなヘッダを付与します。

cache=1

キャッシュ有効。Expiresを30日後にし、Cache-Controlのmax-ageも30日間に設定します。

cache=-1

キャッシュ無効。Expiresを30日前にし、Cache-Controlのmax-ageは0とします。

cache=0

キャッシュ指定無し。ExpireもCache-Controlも指定しません。

ついでに、画像も用意してみました。同様にサーバサイドで現在時刻の画像を作成して返します。キャッシュ制御も同じです。

検証用画像

これを、テスト用のHTMLで取り込みます。
スクリプトは、scriptタグによる単純な取り込みと、XMLHttpRequestによるAjax通信の2種類。画像はimgタグで指定しています。
前述の3種類のキャッシュ制御を行うページは、次の通りです。

• キャッシュ無効
• キャッシュ有効
• キャッシュ指定無し

これで、ページを開いた時の時刻(正確には、サーバがリクエストを受け付けた時刻)が表示されるはずです。リロードや再訪問時に、キャッシュが効いていれば日時はキャッシュされた時のままになります。

順に見ていきましょう。

キャッシュ無効の場合

いずれの場合も期待通り、キャッシュは全くききませんでした。
ページ遷移を行った場合も、F5でリロードした場合も、全て最新に更新されます。

キャッシュ有効の場合

動作が分かれました。
通常にページ遷移を行った場合は、Opera10を除き一律にキャッシュが使われる期待通りの動作です。(Opera10はまだbetaのため、最終的にどういった仕様になるかは不明です)
F5などでリロードを行うと、画像やscript要素で取り込んだものは、いずれも再読み込みされます。
しかしXMLHttpRequestでの通信は、ChromeやFFでは再通信が行われるのに対し、IEとOpera9ではそのままキャッシュが有効になってしまいました。これはCtrl+F5のようなスーパーリロードを用いても、変わりません。

キャッシュ指定無しの場合

かなり無軌道になっています。Operaに至っては、通常のページ遷移でも動作に違いが出てしまいました。

ETagについて

StevesSuders氏の検証ではETagについても含まれています。
今回は検証結果を見やすくするために、レスポンス304については確認していません。
氏のページによれば、Safari4はIf-Modified-Sinceを送らずに常に再送信されてしまうようです。

まとめ

1. Expiresを指定しないことは、動作を全く制御しないのと同じこと。可能な限りきちんと、用途にあわせてキャッシュの制御を行うべきです。
2. Ajax通信でキャッシュをされたくない場合(多くの場合、この用途でしょう)、Expiresを過去に指定してキャッシュを無効にしましょう。
3. 或いは、通信にエポックタイムのようなユニークなIDをパラメータに付与し、キャッシュできないようにするのも良い方法です。
4. Ajax通信をキャッシュしたい場合、Expiresをキャッシュしたい期間、きちんと指定しましょう。ただし、その際にはF5でリロードしても更新されないブラウザがいることを知っておきましょう。
5. Operaを対応ブラウザにするならば、バージョン10がどのような仕様になるか注意しておきましょう。

No related posts.

Bytecode cache

バイトコードキャッシュを用いずしてパフォーマンスを語る無かれ(超意訳)

If you care about performance and don’t use bytecode cache then you don’t really care about performance.

というほど、まず重要としているのがこの部分。
まずは(Zend社員としては当然) Zend Serverの導入検討を奨めていますが、自分でPHPをコンパイルできる環境であるならばAPCなどを使えば良いでしょう。ちなみに、このblogを動かしているPHPもAPCを使っています。GUIの管理画面もあってステータス管理も簡単。キャッシュヒット率99.9%。プログラム中からmemcache的に変数を格納したりも出来るし、非常にありがたいモジュールです。

Profiling

最適化する前にプロファイルを!(意訳)

Profile you code before you start optimizing it!

どの関数がボトルネックになっているのか、ちゃんと把握してからチューニングしましょうということで。そのためのツールとしてZend Studio/DebuggerやXdebugが挙げられています。

Caching

殆どのPHPは”shared nothing”でインストールされているわけで、リクエスト処理の終了と同時に作業内容は全部飛んでしまいます。これは処理の複雑さを回避するなどのメリットは大きいのですが、パフォーマンス的にはデメリットですよね。繰り返し処理はキャッシュに入れて、いいとこどりにしちゃいましょう。(意訳)

Most PHP installations run in “shared nothing” mode where as soon as the request processing ends, all the data associated with the request is gone. It has some advantages, but also one big disadvantage – you can not preserve results of repeated operations. That is, unless you use caching.

実際、DBへのアクセスや複雑な計算のような大きな処理はもちろん、XMLによる設定ファイルをパースしておくような簡易な処理でも、アクセス毎に発生するようであればDisk I/Oとあわせてトータルでかなりの軽量化になります。
キャッシュ先としては memcached や前述の APC などが挙げられます。用途によってはHDDでも良いでしょうが、基本的には高速なメモリでのキャッシュを考えるべきです。ポスト元では他にも、Zend Serverに含まれたZend Frameworkによるキャッシュ機能を奨めています。

Optimize your data

通常、PHPアプリケーションで最もコストのかかる処理は、データベースやファイルシステムのような外部データや、ネットワークにアクセスすることです。クエリーを減らすこと、データベース構造の改良、ファイルシステムへのアクセス減、データ取得のためのサービス呼び出しを複数回行わずに1度でまとめるなど、これらの最適化に注力しましょう。更に言えば、システムコールトレーサ(Unixであれば strace、Windowsであれば Process Explorer など)などを使い、スクリプトが呼び出しているシステムコールを減らせないかどうか検討しましょう。それらの全てを除くことは不可能だと思いますが、いくつかは検討の余地があるでしょう。(意訳)

Usually the most expensive places of the PHP application are where it accesses external data – namely, database or filesystem or network. Look hard into optimizing that – reduce number of queries, improve database structure, reduce filesystem accesses, try to bundle data to make one service call instead of several, etc. For more advanced in-depth look, use tools like strace (Unix) and Process Explorer (Windows) to look into system calls your script produces and think about ways to eliminate some of them. You would not be able to eliminate all of them but each of them is a worthy target.

ほぼ、そのまま。
下手にPHPでの処理をいじるより、RDBのチューニングを行った方が遥かに効果的なことは、非常によくあります。また、先述のキャッシュを使うような工夫は、ここにも繋がります。

Don’t try to outsmart the engine

世の中には”Tips”と呼ばれる「ああしたほうが速い」「こうすると遅い」というような話題があります。しかし特にビギナーのうちは、そういったものに惑わされない方がいいでしょう。十中八九は何も変わらず、残った1つも手持ちのコードに容易にあてることは出来ないか、費やした時間ほどの価値は無いというのがオチでしょう。確かにopcodesを軽くしたり、lookupsを減らしたりするような手法はありますが、他の全ての条件が整っていなければ無意味です。加えて、こういったアドバイスのいくつかは、寧ろコードを遅くしたり、堅牢性やセキュリティを失わせてしまったりします。特に初心者は、こういったトリッキーな手法に手を出さない方が良いでしょう。(意訳)

There are a lot of “tips” floating around about which constructs in PHP are faster or slower than others. I think you can safely ignore all of these tips, especially if you’re a beginner. Odd are, 9 cases out of 10 they won’t give you any improvement at all, and in the remaining one case it will be either not applicable in your code or not worth the time spent on it. Yes, there are ways to save couple of opcodes and remove couple of lookups here and there – but unless you’ve already done with all of the previous steps it is not worth it. And some of the advice out there will actually make you code slower, less robust and less secure without you even noticing. So I think for the beginners is better to stay away from trying to outsmart the engine altogether.

この辺が恐らく、Googleの(そして、その他「高速化Tips」と銘打つほぼ全ての)アドバイスに対する反発心に繋がっているのでは。
王道をきちんとおさえるのが近道というのは、何にでも言えることですよね。

Benchmark in real life

ここまでに話題に挙げたアドバイスの多くは、証拠としてベンチマークを使っています。問題は、これらのベンチマークはいつも、ほんの数行の部分的なコードで書かれていることです。しかしながら、実際に実行されなければいけないコードは大きなアプリケーションで、そのような一行コードではありません。(意訳)

Many of the advices I mentioned above have benchmarks as a proof. The problem is these benchmarks always test only a short piece of code. However, you would not be running that one-liner – you would be running the whole big application.

これに続けて筆者は、「勝ち馬を予想するために真空状態でのモデルを使う科学者のジョーク」を引き合いにだしています。
確かに条件が複合的に絡む場合は多く、数行のベンチマーク結果を妄信することを危惧する必要はあります。しかし、現実に「A/Bどちらの方法が速いのか?」と確かめるには、むしろ他の要因を取り払って調べる必要がある場合もあるように思います。ここに関しては、「最終的なパフォーマンスチューニングは、実際のアプリケーションを用いるべき」というアドバイスと捉えれば良いのではないでしょうか。

Leverage the extensions

あまりにも自明のことを言うようですが、それでもPHP extensionで可能となる機能を重複して作っているようなコードを数多く見かけます。PHPには多くの関数があるので、誰か他の人がやっていそうなものを作る前に、マニュアルをチェックしてみて下さい。DOM/SimpleXML拡張も、JSONパーサも、SOAP送受信のための拡張なども、利用することができます。serialize/deserialize関数が使えないのでなければ、独自のものを作ったりするのは止めましょう。
もしパフォーマンスが非常に重要で、あなたがCプログラムを書けるなら(PHP初心者が、全てにおいて初心者だということを意味しませんよね)、独自のPHPエクステンションを作ることを検討してみてください。それは、それほど難しくはありません。(意訳)

That seems too obvious, but I have seen a lot of code that duplicates functions available in some PHP extension. There are a lot of functions in PHP and if you do something that others may have done before, check in the manual. You have DOM/SimpleXML extensions for XML, JSON extension for JSON, SOAP extension for doing SOAP, etc., etc. Do not create custom serialization/deserialization if serialize()/deserialize() would work for you.
If you have some very performance-sensitive bit of script and you can do C programming (beginner in PHP doesn’t mean beginner in everything , consider even making your own extension, it’s not that hard.

Avoid extra notices/errors/etc.

PHPでエラーを抑止することが大変だったとしても、noticeやstrict notice、warningなどが出ないコードを書くよう挑戦してみて下さい。その際、全てのエラーが出力されるように設定したいと思いますが、実運用環境ではエラー表示を決してしないようにしましょう。恥を大っぴらにするだけですから。(意訳)

Even suppressed errors have cost in PHP, so try and write your code so it would not produce notices, strict notices, warnings, etc. You may want to enable logging of all errors to examine that. Never enable displaying errors in production though – it will only lead to a major public embarrassment.

変数の未定義や配列に添え字が無い場合など、noticeエラーを出しておくことは、タイポなどの単純で気付きにくいバグを回避するのに有効です。ちゃんと無くしましょう…と心から思うのですが、一方で「それってスクリプト言語の手軽さ」を失うことでもあるのかなと考えてしまいます。
いっそ変数型宣言必須の”strict mode”みたいなのが欲しいような。

Use php.ini-production as a start

もしphp.iniの設定をするのに、PHPのソースコードに含まれる php.ini-production を参考にしましょう。include pathなど幾つかの項目は変更が必要でしょうが、土台にするには最適です。(意訳)
If you need a set of php.ini settings which would not hurt your performance and not break anything, look into php.ini-production in PHP source. You may need to change a couple of details (e.g. include path) but it’s a good starting point.
マニュアルによると、PHP5.3.0からはphp.ini-development(開発環境用)、php.ini-production(運用環境用)の2つが同梱されているようです。自分はまだPHP5.3を落としていませんが、以前のrecommendedなどとどの辺が違うのか、確認してみようと思います。

Use big realpath cache

リアルパス・キャッシュは、ファイル名や相対パスからユニークなフルパスを取得する際に非常に有用です。初期設定ではこのキャッシュサイズは16kですが、多くの長いパス名のファイルを扱うのであれば、この値を増やすのが良いでしょう。これはディスクアクセスという重い処理を軽減します。(意訳)

Realpath cache is very useful for the engine when it tries to find the unique full name of the file from just filename or relative path. By default, it’s 16K but if you have a lot of files with long pathes, it’s better to increase the size – it would save the expensive disk accesses.

この機能はPHP5.1から実装されたものですが、ちょっと大きい規模のアプリケーションになると、16kという値はすぐに超えてしまうかもという話は、よく聞きます。よほどメモリに困窮していなければ(そんな場合は既にパフォーマンスを云々言っていられないと思いますが)、64kくらい確保してしまうのが良いようです。

最後に、次のように締められています。

ここに挙げた以外にも、もっと多くのことが挙げられると思いますが、既にちょっと長くなりすぎました。一旦ここで終わりますが、あなたの考えをコメント欄で追加してくれると嬉しいです。

There are probably more things that could be said, but this post is pretty long already, so I will end it here and you are welcome to add your opinion in comments.

同じ言葉で、終わりたいと思います。

No related posts.

今回は本書の5章から「へー」と思った、外部スクリプトを他のファイルのロードを妨げることなく取得し、なおかつそのファイルのロードが終わった際に後続のスクリプトが実行されるための方法(複雑)を確認してみます。

SCRIPTタグを減らすテクニック

この技法はまず、jQueryの作者であるJohn Resig氏のblogポスト Degrading Script Tags に端を発します。
まず、次のコードを見て下さい。

<script src="jquery.js"></script>
<script>
  jQuery(document).ready(function($){
    $("div").text("loaded!");
  });
</script>

これを、次のように書けたら幸せだよね、という話。

<script src="jquery.js"></script>
  jQuery("div").text("loaded!");
</script>

これなら、SCRIPTタグが少なくて済むし、コードの依存関係もハッキリする。srcに記述されたファイルのロードが失敗したら中身のコードが実行されない形なら、万が一の場合にもスクリプトエラーにならずに済むと。

次のようなコードを外部ファイル(この例で言えばjquery.js)の最後に加えれば、これが実装できます。

(function(){
var scripts = document.getElementsByTagName("script");
var curScript = scripts[ scripts.length - 1 ];

if ( curScript.executed )
  return;

// ... jQuery ...

curScript.executed = true;
var script = curScript.innerHTML;
if ( script ) {
  jQuery(document).ready(function(){
    jQuery.globalEval( script );
  });
}
})();

もちろんこれは、jQuery以外のライブラリでも適用可能な、非常にクールな手法です。
正直なところ、自分は最初のこのポストが投稿された際にはそれほど感銘を受けなかった記憶があります。それは「スクリプトのロードと実行が連動する」点に私が着目できていなかったからで、単にscriptタグを減らせるシンタックス程度の認識しかありませんでした。
今回改めて読み返してみて、直観的な良い記述方法だなと思いました。

他ファイルのロードブロック問題

見たように素晴らしいテクニックなのですが、この方法にもまだパフォーマンスの観点から改善の余地があるとSteve Sounders氏は指摘しています。
それが、スクリプトのダウンロードが他の外部ファイルのダウンロードをブロックしてしまう問題の回避についてです。

前述のテクニックはjsファイルのロードについては通常の方法であるため、ブロックは発生してしまいます。これを避け、なおかつロード完了とスクリプト実行がきちんと連動するように改良されたスクリプトが、こちらで紹介されています。

function init(){
  jQuery("div").text("loaded!");
}

var domscript = document.createElement('script');
domscript.src = "jquery.js";
if ( -1 != navigator.userAgent.indexOf('Opera')){
  domscript.innerHTML = 'init();';
}else{
  domscript.text = 'init();';
}
document.getElementsByTagName('head')[0].appendChild(domscript);

この呼び出し方と前述のテクニックを組み合わせることで、高速な外部ファイル呼び出しと、そのロード完了に依存するスクリプトの記述が可能になります。

但し、この方法を使うには外部ファイル側に自要素の中身をコールバック(?)する仕組みを埋め込まなければならず、汎用的に使うのは難しくなってしまいます。
将来的にこの記述をブラウザ側がサポートしてくれた場合であればまだしも、現時点では同書の別項で紹介されているOnload技法の方が優れているとしています。
こちらの検証は、また機会があれば。

Related posts:

1. [Javascript] nullとundefinedとfalseと0と空文字と
2. [Web] Google Page Speedでサイトを高速化(3)

知識として「ふーん」という以上には役立たないTipsの、PHPにおける最右翼はこのechoとprintの速度差問題ではないでしょうか。前回挙げたGoogleのページでも、公開当初はあったものの、後に消されたエントリの1つです。
Smartyなどのレンダリングエンジンに慣れていれば、そもそもデバッグ時以外では使わない場合も多いこのステートメントの「速度差」が、果たしてどの程度のものなのかを確かめてみます。

大きな文字列を出力

1Mほどの大きな文字列を出力させてみます。

$s = str_repeat('x', 1024 * 1024);
echo $s."\n";
print $s."\n";
print $s."\n";
echo $s."\n";

実行順序で結果が変わることがあるので、2回ずつ呼んでみました。

echo: 0.005774974823
print: 0.00450992584229
print: 0.0048840045929
echo: 0.00483393669128

誤差の範囲しか、違いを見出すことは出来ませんでした。

繰り返し出力

256bytesほどの文字列を、繰り返し出力させます。

$s = str_repeat('x', 256);
$cnt = 10000;
for($i=0; $i<$cnt; ++$i)
  print $s."\n";
for($i=0; $i<$cnt; ++$i)
  echo $s."\n";
for($i=0; $i<$cnt; ++$i)
  echo $s."\n";
for($i=0; $i<$cnt; ++$i)
  print $s."\n";

print: 0.0117089748383
echo: 0.0106270313263
echo: 0.0104529857635
print: 0.0104429721832

こちらも、わずかに echo の方が速いと言えるかもしれない程度です。

速度差を気にする必要は無い

気にしなければならないほどの速度差は、無いと判断します。
PHP自体のCのソースコードを読めば、printの方が少し余計な処理をしている分だけ遅いのが道理ですが、意識しなければいけないほどではありません。
OSなど標準出力の機構によってはもう少し大きな差が出るケースがあるのかもしれませんが、基本的には動作・シンタックスの違いだけを気にしておけば良いと思います。(これすら、実際には使い分ける必要はまず無いと思いますが)
一応、簡単に違いを挙げておきます。

echoとprintの違い(1) 文法

どちらも関数ではなく言語構造である点は共通しているので、括弧なしに呼ぶようなことが可能です。しかしprintの方が、比較的関数に近しい記述を許されています。
例えば、次のような記述はechoでは出来ません。

$ret = $flag ? print 'true' : print 'false';
echo "return code: $ret";

このコードは、標準出力が成功すれば$flagの値がどうあれ”1″を返します。

echoとprintの違い(2) 引数

echoは複数の引数を取り、これを連続して出力することが出来ます。

echo "x", "y", "z";
print "x"."y"."z";

カンマで渡した方が、若干高速なようです。(これもよくきくオカルトですし、実際に逆の検証結果もあるようですが、自分の方で試した結果はやはり文字列結合より引数渡しの方が、やや速いようでした)

Related posts:

1. [PHP] 高速化Tipsのオカルト(1) 関数への参照渡し

先日は、にわかに高速化づいているGoogleも、サイト高速化に関するコミュニティをオープンさせました。その中には、PHPに関するパフォーマンスTipsも含まれています。ところが、これも「オカルト」に毒された誤った内容が多く指摘され、公開から僅か1週間で何度も書き直されるような事態になっています。

ここでは巷間に溢れるPHP高速化Tipsの幾つか怪しいものを検証してみます。
※なお、検証に使ったPHPのバージョンは5.2.9です。

大きな配列はポインタで渡す?

PHPには厳密な意味でのポインタは無く、zvalのリファレンスということになりますが。
関数内で元の変数を参照するだけの場合でも、変数のコピーが行われないように参照渡しにする開発者を見かけます。しかし、少しPHPの内部構造を学べば、copy-on-writeの仕組みによってその必要が無いということを知っていると思います。
しかし、実際にはやはり値渡しとポインタ渡しは、値の変更が無かったとしても「同じ」ではありません。
関数内での変数の扱い方によって、速度が変わることを確認してみましょう。

foreach

まずは、foreachを使って大きな配列にアクセスしてみます。

function test1($a){
  $c = 0;
  foreach($a as $v){ if($v=='xxxxx') ++$c; }
}
function test2(&$a){
  $c = 0;
  foreach($a as $v){ if($v=='xxxxx') ++$c; }
}
$x = array_fill(0, 1000000, 'xxxxx');
test1($x);
test2($x);

時間を測るあたりのロジックは割愛しますが、以下、結果です。

time: 0.627353906631
time: 0.374164819717

参照で渡した方が速くなっています。これは結局、test1でforeachが値のコピーを作る際に配列全体のコピーを行ってしまうためです。メモリ使用量を考えても参照渡しの方が優位ですが、これほどの巨大な配列でなければ気にするほどではないと思います。

for

次に、foreachではなくfor文を用いて、変数のコピーを行わずにアクセスするパターンを見てみましょう。

function test1($a){
  $cnt = count($a); $c = 0;
  for($i=0; $i<$cnt; ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
function test2(&$a){
  $cnt = count($a); $c = 0;
  for($i=0; $i<$cnt; ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
$x = array_fill(0, 1000000, 'xxxxx');
test1($x);
test2($x);

処理としてはforeachのものと同じです。結果は、次のようになりました。

time: 0.508368015289
time: 0.736795186996

処理速度が逆転してしまっています。これは逆にメモリコピーが行われなくなれば、リファレンスやfunction-stackの追跡が挟まる分だけ少し遅くなってしまうということです。

for + count

更に、もう1つ確認してみましょう。

function test1($a){
  $c = 0;
  for($i=0; $i<count($a); ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
function test2(&$a){
  $c = 0;
  for($i=0; $i<count($a); ++$i)
    if($a[$i]=='xxxxx') ++$c;
}
$x = array_fill(0, 10000, 'xxxxx');
test1($x);
test2($x);

countをループの外に出さず、毎回評価しています。これも高速化Tipsの基本ですが、ついつい手抜きをして、このようなコードを書いてしまう人も多いのでは。
この実行結果は、次の通りです。

time: 0.00851798057556
time: 20.5319070816

驚くべき結果になりました。
実はこのテスト、前のものに比べて配列のサイズを2桁下げています。test1の所要時間が短くなっているのはそのためで、決してこちらの書き方が高速というわけではありません。
それにしても、このtest2の眼を疑うような劣化ぶりは、どうしたことでしょうか。良かれと思ってわざわざ参照渡しにしたはずが、悲惨なまでにパフォーマンスを劣化させる結果になってしまいました。

結論としては、関数内で値を直接変更しなければいけないような必要性が無ければ、PHPのcopy-on-writeに委ねたコーディングをするのが正解だと思います。
そして、countはちゃんとループの外に出しましょう

Related posts:

1. [PHP] 高速化Tipsのオカルト(2) echoとprint

使ったのは、v.2から実装されたスライドバー。ここに、現在表示中のページに付けられているブックマークを表示します。
「このページ、どのくらい注目されてるのかな？」と思った時に、割と手っ取り早く分かって便利なんじゃないかと。
現時点で対応しているのは「はてなブックマーク」と「livedoorクリップ」だけです。

概要

Mozillaが開発中のFirefoxプラグイン、Jetpackを用いて作ってみたブックマーク表示ツールです。

左側に開いているのグレーのエリアが、今回作ったFeature。ここに、現在のページのブックマーク数が表示されます。

自由に開け閉めできますが、開きっぱなしにもできます。タブの移動やページ遷移でもチェックに行くので、鬱陶しかったら閉じてしまうのが良いかと。

インストール方法

まず、なにはともあれJetpackをインストールしてください。

次に、Social-Screwをインストールします。
上記リンクを辿った先のページにFirefoxでアクセスすると、ページ上部にインストールを促すバーが表示されます。ここで”Install…”ボタンを押すだけです。
しかし何分非公式のサイトなので、非常に危なそうな警告ページが表示されてしまいます。しかしここは気にせず、ページ下部の”I know what I’m doing. Install it!”をクリックしてください。

これで完了のはずです。
プラグインの設定やタブの表示位置によって若干異なるのですが、概ね左上あたりに青い矢印が表示されているでしょうか？これがスライドバーの開閉スイッチになっています。
マウスを近づけるかクリックすると、左端が少し開いてネジの頭が表示されると思います。(先ほどのスナップショットでも見えます)
これをクリックすると、表示領域が開きます。閉じるには、先ほどの青い矢印をもう一度クリックします。

コード

githubにホスティングしておいたので、興味のある人は見てみてください。
試行錯誤しながらだったので綺麗なコードとは言いがたいですが、100行ちょっとの短いコードです。
Jetpack APIリファレンスやjQuery日本語リファレンスなどと併せて見れば、簡単に読めると思います。

今後の展開

本当はtomblooのような、ここから投稿まで出来るツールを作りたかったのですが、ID/PWDをセキュアに保存する良い方法が無かったので、断念しました。
自分個人用ならjetpack.storage.simpleで保存してしまっても良いのですが、公開するとなるとさすがに…
それこそtomblooのようにAPIを認証させて使うのではなくPostをエミュレートするような形で実装するのが良いのかもしれませんが、そこまでやるパワーは無く。

結局、単純にブックマーク数を表示するだけのものですが、これはこれでと思います。
# これを作ってみて、世の中変な人が多いことに気づきました :-p

本当はdeliciousを入れたかったのですが、URLをJavascriptでMD5にするのがメンドウで、今回はパスしました。Y!は基本的にはAPI公開してないし。もし要望があれば考えます。

注意事項

冒頭でも書きましたが、Jetpackは未だ実験段階の機能です。
動作の怪しい部分は多々ありますので、導入する場合はあくまで自己責任でお願いいたします。

Related posts:

1. [Jetpack] v.2リリース：スライドバー搭載
2. [Jetpack] インストールと開発環境構築準備
3. [Jetpack] Screw!ボタンをつけてみる