タグ

2016年7月6日のブックマーク (6件)

  • MySQLでSQLのみを使用してランダム取得を劇的に早くする方法 - 僕のススメ。

    MySQLでランダムに20行をとるためには以下のようにやればいい。 SELECT * FROM table_name ORDER BY RAND() LIMIT 0, 20; 簡単に取得できるのはいいんだけど、行数が増えると劇的に遅い。どれくらい違うかって言うと10万行のデータベースでも↓ぐらい違う。 表示中の列 0 - 19 (20 合計, クエリの実行時間 0.0070 秒) SELECT * FROM table_name LIMIT 0 , 20 表示中の列 0 - 19 (20 合計, クエリの実行時間 1.1884 秒) SELECT * FROM table_name ORDER BY RAND() LIMIT 0, 20; なんでこんなに時間がかかるのかと調べてみると、どうも*を使うから遅いらしい。ということで、列名に主キーを指定して試してみる。 表示中の列 0 - 19

    MySQLでSQLのみを使用してランダム取得を劇的に早くする方法 - 僕のススメ。
  • PHPで高速オシャレな配列操作を求めて - Qiita

    PHPには大量の配列操作関数が用意されています。 これらの関数、イマイチ書き味が悪いということで、よくPHPがDISられるポイントになっています。 お題として、こんな感じのコードを書きたいとしましょう。(意味は特にないです) 0~10000のうち、偶数だけを抽出して自乗し、結果が20を超えるものを足しあわせよ array_xxx系の関数だけで入れ子にしながら書くとこんなことになります。 echo array_sum( array_filter( array_map( function ($v) { return $v ** 2; }, array_filter(range(0, 10000), function ($v) { return $v % 2 === 0; }) ), function ($v) { return $v > 20; } ) ); 読めたもんじゃないですね。 関数の

    PHPで高速オシャレな配列操作を求めて - Qiita
  • N+1問題 / Eager Loading とは - Rails Webook

    N+1問題とは SQLクエリが 「データ量N + 1回 」走ってしまい、取得するデータが多くなるにつれて(Nの回数が増えるにつれて)パフォーマンスを低下させてしまう問題です。 次のように、何度もクエリが走ってしまい、その度に0.1msほどかかってしまってます。 Processing by PostsController#index as HTML Post Load (0.2ms) SELECT "posts".* FROM "posts" User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 1]] User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id",

    N+1問題 / Eager Loading とは - Rails Webook
  • x86でdoubleがfloatより速いかどうかを検証してみた - Qiita

    昔話 それは昔々のこと。 x86には浮動小数点演算を行う手段がなく、外付けの浮動小数点演算ユニットを接続するという手法で、浮動小数点演算を実現していたのであった。 x87と呼ばれたそれはとてもエクセレントなシステムで…という話はwikipediaに譲ろう。 https://ja.wikipedia.org/wiki/Intel_8087 重要なのは、x87が内部表現として80bitの拡張倍精度を使っている、ということ。 これのおかげで、x87においては、確かにdoubleのほうが速かった (floatだとdoubleへのキャストコストが発生するため) 嘘だろそれ。ASM見たら別にキャストとかしてなかったわ。 どっちかというと丸めの影響で精度が異なることのほうが重要だわ。 改めて調べてみると、doubleが速いとされている資料についてはあんまりないことに気付く。 (同等としている資料はher

    x86でdoubleがfloatより速いかどうかを検証してみた - Qiita
  • (修正)float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め

    すみません、以前のプログラムにポカがありました 以前、以下のエントリーを書きました。 float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め http://d.hatena.ne.jp/nakamura001/20090226/1235641233 そして今回、この速度差がどこから来てるのかアセンブリレベルで検証しようと色々と前回のプログラムを見直していたところ大ポカをやらかしている事に気がつきました。 具体的には以下の様な部分です。 NSLog(@"double : time=%f\tval=%f", elapsedTime, floatTotal); こちら double での計算結果なので来でればここで指定するのは floatTotal ではなく doubleTotal です。 このようなポカをやらかしたせいで doubleTotal

    (修正)float型とdouble型を比較した場合、常にfloatが速いと思ってはダメらしい - 強火で進め
  • Cプログラミング診断室/キャストが好き/float型対double型

    ■float型は遅い■ この人は、どうもdouble型を嫌っているように思えます。可能な限りfloat型で計算しようとし ているようです。やはり、double型より、float型の方が高速に違いないと思い込んでしまってい るようです。 結論から言うと、ほとんどのCでは、float型よりdouble型で計算した方が数倍高速になります。 例えば、今私がこの原稿を書いているコンピュータ(SPARCstation IPX)で、 r += 0.1 を計算させ ると、rがfloat型だと0.36μ秒ですが、double型だと0.11μ秒になります。 不思議に思われる方も多いと思います。もしあなたがアセンブラを理解できるのでしたら、簡単 な数行のプログラムを組んで、double型とfloat型のときのコンパイルされ方の違いを調べてみる と良いでしょう。 ここでは、アセンブラ・ソースを直接眺めながら説明す