まつもと直伝 プログラミングのオキテ 第18回 プログラムを高速化する（その2）：ITpro
プログラムの高速化については本連載の第13回で紹介しています。プログラム中のどの部分を高速化すべきなのか，どのように効果を測定するのか，そもそも高速化が必要なのかを考察しました。今回は実際に高速化を試みます。 今回はプログラム高速化の実践編として，ある程度の大きさの具体的なプログラムを段階的に高速化しながら，実践的なテクニックを学ぶことにしましょう。 例題はマンデルブロ集合＊1の計算プログラムです（図1）。マンデルブロ集合は非常に美しい集合ですから，本当はグラフィックス表示が好ましいでしょう＊2。しかし，GUIを使うと，特定のGUIライブラリ（グラフィックス・ルーチン）に依存したコードが大量に必要です。今回のテーマは「高速化」ですから，直接関係のないGUIコードはできるだけ省くため，キャラクタ（英文字）で図形を表現することにしました。 1 require 'complex' 2 3 def
第4回 Railsアプリケーションをもっと速く | gihyo.jp
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか？ そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
