SQLが苦手なオブジェクト指向屋さん

なんか炎上してるらしんだけど、なぜ炎上するのかわからない。ごく当たり前のことを言っているようにしか見えないのに、なぜあんなにアンチが湧くのか理解に苦しむ。ちっぽけなプライドの問題?

2.SQLオブジェクト指向言語の数十倍の効率

 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十%も変わらない。

 SQLオブジェクト指向言語を比べたら、数百〜数千%の差が付く。

炎上したのでまとめ:ベンチャー社長で技術者で:エンジニアライフ

まあ、そうだよね。SQLでできることはSQLでやったほうが高速 (例外もあるだろうけど少数)。
スクリプト言語Javaとの速度差なんて、下手なSQLひとつで吹っ飛んでしまう。そういうのを経験すると、SQLがいかに重要かが身に染みてわかるし、ほかにも「言語の速度 != アプリケーションの速度」というのは当たり前のこととして受け入れられる。でもSQL知らない人ほどそれが受けいれられない。

でも、SQL難しいわ。学習コストが高すぎる (だからこそ、マスターしたら武器になるんだけど)。

■ 何が問題か

 分業化すれば互いに専門家として尊重しあえるけれど、残念ながら分業化できない。分業化できない最大の理由は、オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから

 オブジェクト指向言語が気になって仕方がない。好きだし、新しいし。それは悪いことではないが、技術者側の都合でしかない。新しいモノの追求はしたらいいけれど、必要条件の効率にどれだけフィードバックできるかという観点がなければならない。

 つまり、SQLが古かろうと気に入らなかろうと、数百〜数千%の差が付くなら、まずそれをきっちりやるべき。新技術を取り入れるかどうかは、数百〜数千%以上の差が付くかどうかで検討すればいいけれど、残念ながらRDBMSを使うのに分業化していないうちは、そんなモノは存在しない。分業化できれば、SQLが比較対象から外れるので、更なる効率化の余地はいくらでもありますけどね。

(強調は筆者による)

『既得権』という言葉が妥当かどうかはわからないけど、言いたいことはわかる。オブジェクト指向言語に詳しいのにSQLが苦手という人は多い。そして、そういう人はなぜかSQLができないくせに勉強しようとしない。実は逆もしかりで、SQLも業務知識もよくわかってるおじさんが、オブジェクト指向についていけてないことも多い。どっちもどっち。

分業については、O/Rマッパー次第としかいえない。

あと、「NoSQLが流行ればSQLを覚えなくて済む」と勘違いしている人もいるだろうけど、違うよね。SQL+RDBMSで難しかったことがNoSQLでは簡単に実現できたりするけど、逆にSQL+RDBMSで簡単にできたことがNoSQLでは難しかったりする。NoSQLは、SQLRDBMSとはまた違った難しさがあるから、勉強しなきゃいけない点ではいっしょだと思う。

JSPが遅い理由をJava屋さんはまるでわかってないらしい

なんかVelocityもJSPもスクリプト言語より遅いという事実は、Java屋さんはあんまり知らなかったみたいだね。しかも、遅い原因の考察が的外ればかりで笑ってしまう。
Javaの文字列操作は遅いから」とか「UTF-16の変換に時間がかかるから」とか、そんなのまるで関係ないですから。Javaの文字列操作は十分速いし、UTF-16の変換も主要因ではない。
#つうかさ、「Javaの文字列操作は遅い」とか、Javaに対して失礼だろ。

続きを読む

Rubinius 1.0.0 が速すぎてびっくりした

(追記: Rubiniusとは、Ruby自身で書かれたRubyの処理系。Javaで書かれているJRubyとともに、期待を集めているRuby処理系のひとつ。)
そもそもこのブログは Rubinius で遊んだ結果を紹介するために始めたようなものだったのに、せっかく Rubinius 1.0.0 がリリースされたのにスルーしてた (ごめんよ Evan)。

ようやく Rubinius をインストールしてベンチマークをとったので、衝撃的な結果とともに紹介する。

続きを読む

高速なプログラミング言語が生み出す本当の価値

なんか、はてなブックマークとか見てると残念なコメントが多いよなー。『こんな比較は意味ない』とか『できることがまったく異なるテンプレートを並べて比較されても』とかいうやつ、何なの?「言語の速度 != アプリの速度」という主張を示したベンチマークなんだから別におかしくないじゃん。主旨がまるで分かってもらえてない。ネットワークやデータベースの処理まで含めて計測したら、「言語の速度 != アプリの速度」という主張がより鮮明になるだけじゃね?

反論する人があまりに残念な反論しかできないようなので、かわりに自分で「高速な言語を使う理由」を説明する (一人マッチポンプ状態じゃねーか)。

続きを読む

プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ

まずは次の表をご覧あれ。これはプログラミング言語ベンチマークとして有名な Computer Language Benchmarks Gameベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。

これを見れば、最速な言語は C/C++ であり、JavaHaskellOCaml といった静的な言語は軒並み上位に登場する。これに対し、RubyPythonPHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。
(ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が本当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれだけ優秀な JIT を搭載しているかが大事ということがいえるかもしれない。)


   ・  ・  ・  ・  ・


さて、スクリプト言語は軒並みトロいということが分かったうえで、次のグラフをご覧頂きたい。これは各プログラミング言語でのテンプレートエンジンのベンチマーク結果である。約3年前の結果なのでバージョンは古めであるが、今でも参考にはなるはず。Test1 はテンプレートを毎回読み込むテストであり CGI 向け、Test2 はテンプレートを最初の1回だけ読んで使い回すテスト*1であり FastCGI や mod_xxx 向けである *2


(クリックで拡大)

これを見ると、Java や C で実装されたテンプレートエンジンが必ずしも最速ではないことが分かる。たとえば Velocity は Java の有名なテンプレートエンジンだが、実は性能は eRuby にすら劣ることがわかる*3。また C で実装された Cheetah や Template-Toolkit も、pure Python や pure Perl なテンプレートエンジンに思いっきり負けている。さらに、さきほどの言語別ベンチマークでいちばん遅かった PHP が、このベンチマークでは最速の地位にいる*4

またこのグラフには出てないが、JSP は Velocity より遅いことが分かっている。そもそも Java は静的であることが強みのはずなのに、Velocity にしろ JSP (EL) にしろ動的な言語を導入しているのだから理解に苦しむ。わざわざ Java の強みを捨ててまで、動作も遅くなるものを導入する必要があったのだろうか。あるいは <c:out/> のかわりに ${fn:escapeXml()} を使うとか、性能に無頓着すぎるだろ*5

Java のように高速な言語でも、Velocity や JSP のようなアーキテクチャではたいして速度は出せない。逆に RubyPHP のようにスクリプト言語の中でも遅いと言われるものでも、正しいアーキテクチャを採用すれば十分な速度は出せる。言語の速度を気にするのも結構だが、もっと重要な要素があるんだからそっちを気にしたほうがいい。


   ・  ・  ・  ・  ・


このように、プログラミング言語の速度とアプリケーションの速度は、必ずしも一致しない。一致しないどころか、まるで関係ないと言っても差し支えないぐらいである。もちろんテンプレートエンジンの速度でアプリケーションの速度を測れるわけではないが、「必ずしも一致しない」という結論は変わらない。

だから、たとえばPHP と Perl とをちまちま比較してもいいけど、その程度の差でどちらが速いかを結論づけても大して意味はない。それより「PHPPerl (や RubyPython) ではこの程度の差しかない」ことが認識できればそれでよく、あとは各自アプリケーションのチューニングにいそしむべきだろう。少なくも「PerlPHP より速いんです (キリッ」と言いながら Template-Toolkit を喜んで使っているやつや、「Java は速いんです (キリッ」と言いながら喜んで ${fn:escapeXml()} 使ってるやつは何も分かってないから、そんなやつらがいたらハナで笑ってよい。


今日のまとめ:プログラミング言語の速度 != アプリケーションの速度


なお複数の言語を使ったベンチマークでよさげなのがあれば紹介して下さい。ぐぐってみた限りでは他によさそうなのが見つからんかった。

*1:つまり Test2 であればディスク I/O の影響はほとんど受けない。ファイルキャッシュを考えると Test1 もほとんど影響をうけないと思われる。

*2:このベンチマークでは HTML エスケープはやってないが、HTML エスケープすると性能はだいたい半分に落ちると思えばよい。

*3:Velocity は 1.6 で速度がもう少し向上しているので、今なら eRuby に勝っているかもしれない。

*4:なおこのベンチマークでは Perl があまりぱっとしないが、Perl の潜在能力はこんなもんじゃないことを付け加えておきたい。

*5:${fn:escapeXml()}はELレベルでの関数呼び出しになるから、<c:out/>よりかなり遅い

Re: スクリプト言語の息の根を止めるのは案外 SSD かもな

まえのエントリのコメント欄より:

flat8 2010/04/27 10:19
確実にIntelはそこまで考えていると思います。で、ある程度SSDが普及したらSSD自体の製造からは手を引くでしょうけど。

やはりそうでしょうか。さすがIntel
ところでIntelが『SSD自体の製造からは手を引くでしょう』という根拠は何でしょうか。CPU ほどは儲からないからかもしれませんが、減価償却の終わった製造施設で生産できるなら、Intel としては悪くない分野だと思うので、製造は続けていくように思います。

通りすがり 2010/04/27 11:31
クライアントコードの処理時間(コスト):バックエンドの処理時間(コスト)の考察無しには、SSD時代になったとしても一概にスクリプト言語不利とも言えないのではないでしょうか。

SSDによりディスクI/Oのボトルネックが大きく軽減されることは、スクリプト言語にとって不利になるのは間違いないと思います。あとはそれがどのくらい不利かが問題。さほどの不利ではないという考えも当然できますが、それは人によって判断が異なるでしょう。

yuki_hero 2010/04/27 12:10
まぁ、巨大な企業は、社会基盤そのものにも目をつけていますから...

目をつけられない頭の悪い企業も多いですけどね。特に日本は。

cpw 2010/04/27 12:43
アプリケーションサーバは分散が容易とういうことを忘れてはいけませんよ。サーバも安くなってきてますしね。人件費の方が高コストです。

アプリケーションサーバは分散が容易』ですが、数千台・数万台という規模になると、さすがにそうもいってられないでしょう。サーバ自体は安くても土地代や電気代や光熱費はばかにできませんし、もし仮にですがスクリプト言語を止めることでサーバ台数が 1 ケタ減らせるぐらいの効果があれば、さすがにスクリプト言語は使わないと思いますよ。あくまで仮定の話ですが。
あと『人件費の方が高コスト』というのはその通りですが、今の話とどう関係が?スクリプト言語のほうが人件費を削減できるとでも?

Goat 2010/04/27 13:02
ボトルネックになるのはストレージだけではないでしょう。PHPはもちろん、RubyPythonPerlも多くはウェブ系のシステムに使われていると思いますが、そういう場合ではネットワークがボトルネックになってきます。
そして、スケールアップよりもスケールアウトという流れの中でますますその傾向は強くなっています。

仮にコードがボトルネックになったとしても、多くの場合はアルゴリズムに問題があるのであって、そこを改善してオーダーを変えてしまえば、5倍〜10倍の差なんて問題にならなくなりますし、そもそもタイムクリティカルなミドルウェアでは今でもCやC++が主流なのでSSDスクリプト言語に与える影響はほとんどないのではないかと思います。

はい、ボトルネックはストレージだけではありません。しかしストレージ以外のボトルネックも将来は解消される可能性が十分あり、そのときに備えて手は打っておくべきだと思います。
あと『多くの場合はアルゴリズムに問題がある』というのは本当に実感します。これについては別途エントリを書きます。

通りすがり 2010/04/27 13:44
インタプリタコンパイルかで速度が極端にかわるようなら、単純にPerl,PHP,Ruby,Python等で静的コンパイルできるようにするんじゃないかなぁ〜?

インタプリタ型言語も内部的にはコンパイルしてから実行してますし、さすがにこのコメントは的外れでしょう。

muha 2010/04/27 13:51
逆にますますインタプリタが使われると思う。 人件費より高いの無いでしょ

んー、インタプリタだと人件費が抑制できるという主張でしょうか。その根拠は?Java開発者よりPHP開発者のほうが単価が安いということ?

とことこ 2010/04/27 14:38
確かにトランザクションが多いところはそうなるかもしれない、
よく知りませんがスクリプト言語の作成効率が高ければ、そんなにトランザクションがおきないところは安く構築するために有効だと思われるので、そんな劇的にシフトはしない気がする。

これも「スクリプト言語のほうが安く済む」という前提のコメントですね。その根拠って何でしょうか。

Taruryun 2010/04/27 17:08
元のテストの結果は、僕が読む限り、
処理能力が頭うったのは
『DBサーバの』CPUに読めるんですが・・・。

もし息の根止められるとしたら、フロント用アプリケーションを書くための言語もろもろではなく、「SQLというスクリプト言語」でしょう・・・

元のテストは確かにDBサーバが対象ですが、「SSDによってディスクI/Oのボトルネックが解消されるとスクリプト言語にとっては不利である」という考察は、DBサーバかどうかに関係なく成り立ちますよね?

apollo440 2010/04/27 21:46
いやいやいや、”全”プログラマーって。ストレージ使うのが当たり前じゃない世界もあるし、もうちょと範囲狭くして欲しい気が。

あと、(人気の)スクリプト言語は、「使いやすい」じゃなくて「遊びにはよい」かと。

まあ『ストレージ使うのが当たり前じゃない世界もある』のはその通りですが、元記事の興味深い結果はストレージに関係ないプログラマでも知っておくべきでしょう。

noname 2010/04/28 00:56
C++, javaで生活している者から一言


スクリプト屋(笑
が必死だなw

お互い様ですね。

negi 2010/04/28 18:04
仕事でjavaからphpに移って6年くらいだけど、
スクリプト言語
実行速度やコード書く速度とかより
バグが激しくてテストが半端ないよ。
誰かが書いたソースを使いたく無いし、
使おうと思うとソースの細部まで読まなきゃならなくなる
せめて返却値くらいは型を決めてくれ。
NULLの場合とBoolの場合とがあるって糞でしょ?
あとExceptionもだね。

俺もOCamlが何で流行らないのか疑問なんだよね。
OCaml関数型言語で手続き型から移行しやすい言語だと思う。
まあデフォルトで日本語使えねーって事もあるかもね。
camomileも開発止まってるのかな?
他はHaskellに期待してます。

スクリプト屋は一度、静的型付けの関数型言語をかじった方がいいと思うよ。

前半は言語よりも開発者の能力に大きく依存する話。C++Javaでその問題が解決するわけではありません。
後半のOCamlについては、単に普及させようとする人の熱意と戦略が足りないだけだと思います (怒られそうだけどあえて言う)。最後の一文は強く同意します。逆にC++Java屋さんはスクリプト言語をひとつぐらいマスターすべき。