BEAR Blog

Because everything is a resource.

Hello Worldコールグラフ

| Comments

Hello Worldベンチマーク

Performance of YiiというページでPHP主要フレームワークの”hello worldべンチマーク”を比較しています。phpmarkというGoogle Code Projectでホストされてる各フレームワークでHello Worldを出力するアプリケーションでベンチをとっているようです。Hello Worldベンチは最小のオーバーヘッド測定のためとされますが、そのコールグラフがどうなるかに興味を持ちました。

※なぜHello Wolrdなのか?どういう意味があるのか?などについてはPerformance of YiiPaul M. Jones » Blog Archive » New Year’s Benchmarksなどを参照してください。

コールグラフとは?

コールグラフ (マルチグラフとも呼ばれる) とは、コンピュータプログラムのサブルーチン同士の呼び出し関係を表現した有向グラフである。

コールグラフ – Wikipedia

コールグラフ描画にはfacebookの開発したxhprofが描画するgraphvizを用いました。web上で描画されたものです。以下、コールするファンクションの少ない順に並べています。

Yii1.0.3Lite

ファンクションコール数:119

PHP APC extension が有効である場合、 yii.phpを yiilite.php で置き換えることがで、さらにパフォーマンスを改善できます。
yiilite.phpはすべてのYiiリリースに含まれています。その内容はYiiの基本クラスをひとつにまとめたものです。コメントとトレース命令はすべて取り除かれています。したがって、yiilite.php を使うことで、インクルードされるファイルの数と、トレース命令の実行を減らすことになります。

というものだそうで、アプローチの仕方はちょっと違うようですがKohanaにもKohana-liteというものがあります。1

そのたっぷりつまったyiilite.phpの読み込みに最も時間がかかっています。

Yii 1.0.3 Lite

Yii 1.0.3 Lite

Yii 1.0.3

ファンクションコール数:161

YiiはHello Worldベンチの性能が良い原因を「他の遅いフレームワークは必要が無いかもしれないモジュールを初期化しているが、Yiiはレイジーロードを積極的に採用しているため」と説明してますがこのグラフを見る限り最低限のものしか呼び込まれていないすっきりした印象を受けます。

Yii 1.0.3

Yii 1.0.3

CodeIgniter 1.7.2

ファンクションコール数:377

Yiiの次にファンクションコール数が少ないのがCodeIgniterです。他のフレームワークと違うのはフレームワークの関数のものがあることでしょうか。最もコールされてるのがload_classの17回、get_config, log_messageと続きます。どれも関数です。

CodeIgniter 1.7.2

CodeIgniter 1.7.2

Zend Framework 1.7.3

ファンクションコール数:725

Yii, CIに続くのがZend Frameworkです。今回のフレームワークの中で唯一、クラス/メソッドの命名規則がPEARと同じで僕は一番分かりやすく感じました。最もコールされたのはZend_Loader_PluginLoader::_formatNameで17回、時間がかかったのはZend_Controller_Action_Helper_ViewRenderer::getInflectorで全体の5.1%です。

Zend Framework 1.7.3

Zend Framework 1.7.3

symfony 1.2.2

ファンクションコール数:1878

もっともカオスなコールグラフになったのがこのsymfonyで7489 x 5683ピクセルの巨大グラフになりました。sfConfig::get()が147回呼ばれ最も時間のかかったメソッドになっています。

symfony 1.2.2

symfony 1.2.2

CakePHP 1.2.1

ファンクションコール数:12,166

コール数が桁違いに多いので何かの間違いではないかと思いましたがMASA-Pさんの【CakePHP】xhprofでCakePHPのパフォーマンスを丸裸にする | ECWorks Blogという記事でも13,000を超えるコール数になっているのでこれで間違いではないと思います。特にFolder::系のコールが多いようです。
グラフのサイズはややsymfonyより小さいですがほぼ同等です。

CakePHP上位コールファンクション

CakePHP 1.2.1

Disclaimer

phpmarkのサイトにもあるのですが、このエントリーでも同じです。

  • 特定のフレームワークを応援したり攻撃する意図はありません。
  • ミニマムオーバーヘッドが低いというのはフレームワーク評価基準のごく一部です。フレームワーク選定で重視しすぎるべきではないでしょう。

関連リンク

  1. アクティブじゃないみたいですが []
  2. 上記の他にPrado, Solar, Agavi, Drupalのベンチとコールグラフがあります []
  3. 下のリンクの記事Entertaining But ~と合わせてどうぞ []
  4. ということでこのエントリーも… []

BEAR

| Comments

MVCにはあまりにも多くの派生パターンがあるので、「あなたが言っているMVCは私のMVCと違うね」みたいなことが頻発する。いっその事、MVCは NGワードにしたほうがいいんじゃなかろうか、とは俺も思う。

matarillo: UIパターン

現在のSmalltalkの世界では、すでに Model – View – Controller というナイーブなアーキテクチャは使われておらず、 Domain Model – Application Model – View – Controller という PluggableMVC (or MMVC) と呼ばれるアーキテクチャに移行している。

結城浩氏 – MVCとはModel-View-Controllerの頭文字をとったものです。

MVCフレームワーク?

リクエストを受け取ったフロントコントローラ内がURIを解析し、ルータやディスパッチャでモデルやビューが呼ばれるものをごく一般的なWeb MVCアプリケーションフレームワークだとすると、BEARは数々の相違点があります。

MVCは責務という関心の分離1ですが、そこだけに注目すればBEARのPage-Resource-ViewはMVCのバリエーションの一つかもしれません。ですがコンポーネントの働きとやり取りに大きな違いがあります。最大の相違はモデルの部分です。BEARのモデル(Resource)はオブジェクト設計を前提にされたものではありません。またフロントコントローラーを持たず、ブラウザから入力されたURIが特定のコントローラーやモデルを指す事もありません。URIを規定するのはフレームワークではなくアプリケーションです。

リソース指向アーキテクチャ

コントローラーとモデルの関係や、モデルのあり方にROA2(Resource Oriented Architecture)を持ち込んだのがBEARの基本コンセプトです。モデルはリソースとして扱われ、ページコントローラーからのリソースリクエストは決まった一つの方法しかなく、返ってくるデータもリソースオブジェクトというコード、ヘッダー、ボディを持つただ一つの型でしかありません。ここでリソースはデータであり、APIでもあります。

リソースレイヤー

(BEAR内部の)リソースURIの向こう側に高度にモデリングされた複雑なドメインモデルがあるのか、news.csvファイルが置いてあるだけのかはページ(コントローラー)は感知しません。URIの違いがあるだけです。URLを入力して表示されたHTMLページが高度に洗練されたクラウドで動いてる超システムの結果なのか、ホームページビルダーで作成したHTMLファイルなのかはwebブラウザは感知しないようなものです。そういう意味でBEARでのリソースはレイヤーとして振るまいます。ページからリソースへのアクセスはアプリケーションレイヤーからリソースレイヤーへのアクセスといえ、ビジネスロジックとしてのモデルとは言えません。ここでリソースはサービスレイヤーです。

today/newsリソースとtoday/wheatherリソースを利用するtoday ページ(コントローラー)は、その2つ(today/news、today/wheather)リソースをもつtoday pageリソースとしても扱えます。MVCであてはめると2つのMを扱うCが、一つのMになることができるということです。そのページリソース(page://)というMは別のページからも使えるし、ページをテストするテストコントローラからもアクセスできます。ROAのレイヤリングの原則が適用されます。

Because Everything is A Resource.

オブジェクト指向においてオブジェクトが主役であるように、リソース指向においてリソースが主役です。リソースの制御ですらリソースそのものになるリソース指向がBEARであり、ROAの世界です。何故かというと全てはリソース 3だからです。

参考リンク

  1. 関心の分離 – Wikipedia []
  2. リソース指向アーキテクチャ(ROA)- 岩本隆史 []
  3. Because everything is a resource. []

Startin' Somethin'

| Comments

ということでBEAR Blog開始。春だし、新年度開始だし。

BEARの使い方とかROAやそれをどうフレームワークの実装にしていくか、考えてたことや考えてることを書いてみよう。