タグ

performanceに関するyokochieのブックマーク (114)

  • Cより速いRubyプログラム

    The document discusses various techniques for optimizing the performance of embedded Ruby (ERuby) templates. It describes 7 iterations of improvements to "MyEruby" that reduced the processing time from over 69 seconds to under 1 second. The optimizations included avoiding line splitting, replacing parsing with patterns, tuning regular expressions, inline expansion and array buffers.Read less

    Cより速いRubyプログラム
  • 信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ

    ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止

    信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
  • TechCrunch

    When X (formerly Twitter) launched paid subscription verification, Mistress Rouge, a professional dominatrix, hoped that it would help her advertise to new clients. But paying for the service didn’t

    TechCrunch
  • STL風に使えるマップ型コンテナの紹介と性能比較 - Preferred Networks Research & Development

    最近スマートフォンに乗り換えました。徳永です。 C++は世に数あるプログラミング言語の中では比較的メモリをわない方ですが、それでもメモリ使用量が問題となる場合はあります。そのような場合の対処方法はいくつか有りますが、手軽に選択できる方法として、今日はSTLのmapやunordered_mapと同じ感じで使えるデータ構造をいくつか紹介したい思います。 以下、計算量の表記をする際には、要素数をnとします。 Loki::AssocVector LokiはModern C++ Designというの作者であるAndrei Alexandrescuが開発したライブラリです。AssocVectorはその中の一つとして提供されているクラスで、vector<pair<key, value> >という型のベクターをkeyでソートした状態で持つ事により、二分探索による要素の探索を可能にしたデータ構造です。こ

  • ApacheBenchを使いたいけどApacheを入れるのがだるかったのでベンチマークツール書いた - 時計を壊せ

    なんでこんな事をしたんですか?*1 昨日、コンソール開いたんです。コンソール。 そしたらなんかabコマンド打ってもApacheBench使えないんです。 で、よく見たらなんかApacheが入ってなくて、"command not found: ab"とか書いてあるんです。 もうね、アホかと。馬鹿かと。 お前らな、ApacheBench如きで普段使ってないApache入れるかよ、ボケが。 Apacheだよ、Apache。 なんか沢山モジュールとかも付いてるし。1台何役だよ。おめでてーな。 よーしついでだからこれもこれも使うといいぞー、とか言って色々いれてくるの。もう見てらんない。 お前な、ApacheBenchだけよこしてさっさと消えろと。 サーバーってのはな、もっと殺伐としてるべきなんだよ。 ネットワーク越しのイカれた奴といつ喧嘩が始まってもおかしくない、 落ちるか落ちないか、そんな雰囲気が

    ApacheBenchを使いたいけどApacheを入れるのがだるかったのでベンチマークツール書いた - 時計を壊せ
  • each()は遅い上に微妙な問題も起きやすい - Islands in the byte stream (legacy)

    特別な条件がないかぎり、each()は使うべきではありません。代わりにkeys()/values()を使うべきです。その理由は2つあります。 each()は遅い each()でハッシュ全体をループするのは遅いです。これは、keys()/values()がその内部の値をそのまま参照する*1のに対し、each()は代入しないとその値を使えないからです。 ベンチマーク: #!perl use strict; use warnings; use Benchmark qw(cmpthese); my %hash = map { $_ => $_ } ( 1 .. 10000 ); cmpthese -1, { each_k => sub { while(my $key = each %hash) { } }, each_kv => sub { while(my($key, $value) = eac

    each()は遅い上に微妙な問題も起きやすい - Islands in the byte stream (legacy)
  • ほえほえ LinuxファイルI/Oチューニング

    Linuxは私の使っている範囲ではファイルI/Oがパフォーマンスボトルネックになっていることが多い。で、チューニングの情報を集めてみるのだが、なかなか役立つ情報を入手できない。 決まって全般的なチューニングの進め方について述べ、次にボトルネックの調べ方について述べる。 最後にチューニングパラメータ設定手順のヒントだけを非常に簡単に挙げておわってしまう。いや、どこがボトルネックなのか最初に一発で分かればいいよ? でも全般的なチューニングの進め方でそうしたドキュメントが述べている通り、色々な可能性を繰り返しチューニングしながらつぶしていかなきゃいけないんだよね。 そのためには具体的なチューニングパラメータの設定手順がなきゃできないんだよね。それを教えろよ!それを! ということで、今回はLinuxファイルI/Oチューニングについて調べた。大きなファイルの書き込み(ex. cpコマンド)を行うと、

  • Perlでファイルの一括読込 - D-6 [相変わらず根無し]

    Perlでファイルの一括読込 2011年4月27日 01:19 D | ブログ記事のURL | コメント(0) | トラックバック(0) なんかtwitter見てたらこういうのを貼ってる人がいたので、一応書いておく。 Perlでファイルを一気に読み込むのは local $/; <$fh> が一番速い。 open my $fh, '<', "/path/to/file.txt" or die "failed to open file: $!"; my $content = do { local $/; <$fh> }; いずれにせよ大きいファイルを処理する場合はこういう風に一気に読み込むのは効率悪い。それを分かった上で、それでも1行ずつ改行コードが取り除かれた状態で配列に読み込みたいならこれをsplitするのが一番速い。 open my $fh, '<', "/path/to/file.

  • MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック

    べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ!!などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい!! 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake(MySQL 5.5以降)やconfigure(MySQL 5.1以前)にかかる時間は除いてある。だがそれでも速い。

    MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
    yokochie
    yokochie 2011/04/18
    確かにこれは漢(オトコ)だ
  • clang_complete 〜高速化への道〜 - C++でゲームプログラミング

    さて、以前、vim でコード解析を行うプラグインとして、clang_complete を紹介しました。 補完の精度は優秀ですが、普通に使用すると補完に時間がかかってしまい、ストレスが溜まってしまいます。 clang_complete では、高速にコード解析を行う方法がいくつあるので、今回はそれの検証と結果をまとめたいと思います。 ★高速化する方法 1.pch(プリコンパイル済みヘッダー)ファイルを使用する その名の通り、使用するヘッダーをプリコンパイルして、clang のコード解析時に使用します。 予め、プリコンパイルしておかないとダメなので、ちょっとめんどいかも? 2.libclang libclangは、llvm に付属しているツールの1つで、コード解析を行います。 (Windows であれば、llvm のビルドを行うと libclang.dll が生成される) clang_compl

    clang_complete 〜高速化への道〜 - C++でゲームプログラミング
  • 遅いブログパーツを高速表示する方法

    ブログパーツの表示が遅いと、ページ全体の描画が止まってしまいますよね。 ブログパーツを「非同期化」してしまえば、ストレス無くページが表示されるようになりますよ。 非同期化とは、ページの一部分を、全体のページから独立して描画させる方法です。 方法はいろいろあるのですが、今回はJavascriptの「setTimeout()」関数を利用しました。 setTimeout()は、メインの描画とは別に、指定した時間後に命令を実行する関数です。時間を0にすれば、非同期で動作させることが可能です。 ブログパーツは、主に3つの形に分けることができます。各々の形ごとに、高速化する方法を紹介します。 ●タイプ0 <iframe src=”http://hogehoge.com/blogparts.cgi”></iframe> iFrameのタイプは、すでに非同期化されているため、特に対策は必要ありません。 ●

    遅いブログパーツを高速表示する方法
  • Objective-Cの『遅さ』を計測したら、JavaやC++の5倍も遅かった

    なお、メモリ消費量はtopコマンドで測ったので、かなり大雑把な数字だ。また、Cで同様の処理のコードを書くと、ほぼC++と同じ速度になる。 追記(2011/02/17 8:50):Rubyによるベンチマークを追加。 追記(2011/02/17 11:00):Smalltalkによるベンチマークを追加。ソースコードは「Smalltalkのtは小文字です」のループ回数を修正した。 追記(2011/02/17 16:00):Perlによるベンチマークを追加。 追記(2011/02/18 10:30):Java 1.6.0_22で実行した、Scalaによるベンチマークを追加。また、clang/llvmでC++とObjective Cの値を取り直し、改善が見られないのを確認。 追記(2011/02/18 14:30):Ruby 1.8.7によるベンチマークを追加。1.9.2との速度差については、@IT

    Objective-Cの『遅さ』を計測したら、JavaやC++の5倍も遅かった
    yokochie
    yokochie 2011/02/17
    PHPの遅さに気を取られちゃうな。。。
  • メソッド呼び出しループベンチにSmalltalkで参戦してみる - Smalltalkのtは小文字です

    Objective-Cの『遅さ』を計測したら、JavaC++の5倍も遅かった: ニュースの社会科学的な裏側 ただし手元の環境(MacBook Air 11", 1.6GHz Core 2 Duo, Win 7)は非力なので、ループ回数は 268435455回に減らしました。Cygwin環境であるせいか、Objective-C は元記事でとりざたされている結果と違い、C++ の5倍までは遅くなっていませんでした。かたや JavaC++ の2倍程度に遅くなっていて、Objective-C とはほとんど差がありませんでした。 Smalltalk はまずまずの結果といった感じでしょうか。正直、爆速を誇る商用処理系であるところの VisualWorks には、C++ とまではいかずとも Objective-C には肉薄して欲しかったところですが、前述の通り Objective-C に逃げ切ら

    メソッド呼び出しループベンチにSmalltalkで参戦してみる - Smalltalkのtは小文字です
  • 開発メモ: Kyoto Cabinetのロック機構の改善

    Kyoto CabinetはIO負荷が高い場合にCPU負荷も高くなりがちだという指摘を受けて、それを解決すべくロック機構を見直したという話。 スロットロック ハッシュテーブルの操作はハッシュバケット毎に完全に独立して実行できるのが強みだ。ハッシュテーブルは計算量が有利なだけでなく、並列性にも優れるということ。実際には下層のファイルIOで実装依存の排他制御が行われることになるが、ハッシュ層だけ見れば理想的な並列性を備えている。ただし、同じバケットに連なるレコード群の操作は互いに依存関係があるので、それらは一括して排他制御してやる必要がある。となると、バケット毎にロックを用意するのが理想だが、実際にはメモリを節約するために、予め決めた数のロックを用意して、ここのロックに複数のバケットを割り当てる構成をとる。リソース空間をスロットに分けるというイメージから、これをスロットロックと呼ぼう。 スロッ

  • 卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...

    今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお~」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な

    卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...
  • C言語: 実行時間測定の方法

    C言語において実行時間を測定する為の方法はいくつかある。gettimeofday, clock, getrusage, timesを利用する方法である。ここではこれらの方法について検証してみる。これは2005/12/30時点での情報であり、古い亊が考えられるので注意して頂きたい。さらに、内容のほとんどはmanを移しただけなので、正確な情報を得るためにそれぞれの関数のmanを見ることを強く推奨する。 System: Linux 2.6.12 glibc: glibc 2.3.5-1ubuntu12 gettimeofdayを使用する方法 通常はこの関数を使用するのをお勧めする。 gettimeofdayはSVr4, BSD 4.3準拠である。返り値の型はsys/time.hに定義されるstruct timevalで有る。

  • 開発メモ: DBサーバのnoreplyオプションによる高速化

    Kyoto Tycoonやmemcachedにてnoreplyオプションを使ってパフォーマンスを上げる話。 noreplyの功罪 DBに対する更新操作はその成否を真偽値などとして呼出側に返すのが通常であるが、それを省略することでパフォーマンスを上げることができる。memcachedではnoreplyオプションとして知られている。KTの最新版からは、memcachedプラグインと独自バイナリプロトコルでもnoreplyオプションをサポートすることにした。 noreplyを有効にするとなぜ高速化するのか。クライアントはクエリをsendしただけで、recvをせずに次の処理に移れるからだ。sendシステムコールに渡したデータはカーネルが非同期に処理するので、カーネルとアプリケーションは並列に処理を進めることができる。recvをした場合にはその時点で両者の待ち合わせが発生してしまうのだが、それをしな

  • とあるアプリの開発運用(トラブルシュート)

    SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake

    とあるアプリの開発運用(トラブルシュート)
  • 2010年11月18日 &quot;ミラクルパッチ&quot;にLinusも大喜び!Linuxカーネルを高速化させた233行のコード | gihyo.jp

    Linux Daily Topics 2010年11月18日"ミラクルパッチ"にLinusも大喜び!Linuxカーネルを高速化させた233行のコード Linus Torvalds氏という人は、少なくともメールの中では、かなりはっきりと感情を表に出す。誰かor何かに対して怒っているときは相手を名指しで批判(というより非難)し、逆にうれしいときはあふれる喜びを隠そうとしない。今回紹介するのは後者のほう。「⁠I'm also very happy」「⁠it is a _huge_ improvement」「⁠Good job.」など、喜びと称賛の表現がたくさん書かれているメールだ。 Linus氏を歓喜させたのは、カーネル開発に携わるMike Galbraith氏が書いた233行のカーネルスケジューリングパッチ。このパッチを適用すると、デスクトップ環境においてパフォーマンスが著しく向上するという。

    2010年11月18日 &quot;ミラクルパッチ&quot;にLinusも大喜び!Linuxカーネルを高速化させた233行のコード | gihyo.jp
    yokochie
    yokochie 2010/11/19
    これはすごい!
  • mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店

    Google の Page Speed の Apache module 版 mod_pagespeed をインストールして、ちょっとだけ動きを見てみた。 インストールは Ubuntu に deb パッケージで。 $ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb # sudo dpkg -i mod-pagespeed-beta_current_amd64.debconfig はデフォルトで入るものそのまま。 <IfModule pagespeed_module> SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER ModPagespeed on ModPagespeedUrlPrefix "http://localhost/mod_p

    mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店