$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
はじめに WebKit, Chrome, Firefox, Operaでjavascriptのスピードアップ合戦を繰り広げている結果そのへんのLightweight programing languageより速くなっているのではないか、という予測におおまかな数字を与えるために測ったものです。本当にどちらが速いのかはHTTPサーバ・データベース・アプリケーションによるので、これはあくまでどの程度なのかを知るためのものです。 ユースケース 友だちが100人ずついるAさんとBさんの共通の友だちを探します。データベースから持ってきたレコードを手動でjoinする処理です。今回は言語の実行速度のみを知りたいのでデータベースから持ってくる部分は測る時間に含めていません。 速度を意識した実装はしないで、普段書いているような記述にしています。評価環境はmacBookPro”15 2.4GHz Core i5
Arrayのイテレーション
Arrayの中身を１つ１つ見ながら何か処理をする事がよくある。ActionScriptでは、その実装方法としていくつかのやり方が提供されている。以前から、どの方法が速いのか気になっていたので、それを調べてみた。 大きく４つの方法が考えられる。 方法１：最も古典的(?)な方法 for (var i:int = 0;i < arr.length;i++) 方法２：arr.lengthをfor文の外に出した方法。 var length:int = arr.length; for (var i:int = 0;i < arr.length;i++) 方法３：for each文を使った方法 for each(var i:int in arr) 方法４：Array.forEachを使った方法 arr.forEach(...); それぞれの処理スピードを比較してみた。方法１が一番遅いので、それと比較して
One of the first things I needed to do while building the GeeQE iPhone application was process the CC data dump from Stack Overflow. The dump contains XML files representing tables from Stack Overflow with the largest file being posts.xml weighing in at 1.2G as of September. I decided it would be pretty easy to use Ruby to parse the XML and load the data into MySQL so I went about finding the righ
これまでの JavaScript ベンチマークは、実際のアプリケーションでは見られない処理を計測しているものもあり、今後の Web アプリケーションで必要とされる処理速度を適切に測ることができていませんでした。そこで Mozilla は本日、現実のアプリケーションで必要とされるタスクの処理速度を計測する、新しい JavaScript ベンチマーク Kraken を公開しました。以下、Rob Sayre による Kraken のリリース告知 を翻訳掲載します。 Kraken のリリース新しいブラウザベンチマーク Kraken の最初のバージョンを公開できて嬉しいです。SunSpider、V8 あるいは Dromaemo よりも、Kraken は現実的な負荷や今後のアプリケーションで必要とされる処理に注力したベンチマークです。私たちは、最新のブラウザパフォーマンスを更に向上していく上で、現実的
JS server benchmark: Node.js & Rhino; Part 2 After having tested the pure JS speed of Node and Rhino in my previous post, I wanted to see some actual numbers for serving stuff. Long story short, I grabbed the "Hello world!" examples from both Node.js and Rhino running on Jetty and ran 'ab' on them. I was not able to do high-concurrency tests on my Mac, because Jetty gave up around 100, and Node so
高速化 - uupaaの開発日記で==よりも===が良いと知る。 ↓ 早速実験するけど、速くならないよ、と記事を書いた。 ↓ 等価演算子と厳密等価演算子 in ECMA-262 3rd Edition - 0x集積蔵で型が違えば、厳密等価演算子の方が有利だと説明があった。 ↓ 納得しつつ、同じ型ならどうかと試して、記事の結論に達する。 ↓ プラシーボ効果はもちろんご存知ですよね? - uupaaの開発日記でベンチの取り方のまずさ込みで結果の間違いが指摘される。 ↓ この記事で再度ベンチマーク結果を貼る。 結論 IEでもFxでも同じ型の場合、厳密等価演算子の方がごく僅かに速い（PHPほど明瞭な差は見られない）。型が違えば、型を類推する機能が働くことから、（もちろん得られる結果は変わるが（6=="6"、6!=="6"））厳密等価演算子の方が速く動作する。ただ、今回結果には書いていないが、計測し
非ネットで聞いた話なども含め、ここまでやっても信じない人もいっぱいいるみたいで、そこまで疑う人のためにとりあえずパッチは出しておいたのだが、みんな「怪しいよね」って陰で言うだけで、誰も追試はしてくれなかったみたいだ。他人の書いた、しかもCPU使用率なんて割とどうでもいい系のエントリなんてわざわざ検証する人はそりゃいないだろうとは思うけど、気分が悪いのも確かだ。どうせ誰も試さないなら、パッチ自体は次のネタにとっときゃよかったなぁ…。 http://d.hatena.ne.jp/tkng/20091003/1254578195 では折角なので、検証を。Firefox前提なら、Firebugのプロファイル機能で一発なので、検証用マシン*1で以下のスクリプト実行。 // ==UserScript== // @name google stats // @namespace http://ss-o.n
Firefox 3.5 Preview（3.5b99, ID:20090605162636）がリリースされたばかりだが、そのコードはほぼ完成に近く、性能面でPreviewと正式版の差は小さいと考えられる。今回はこのプレビュー版を使ってパフォーマンスを検証したい。 比較対象の第一グループとして、Firefox 3.5 Beta 4（ID:20090423204732）とFirefox 3.0.10（Gecko/2009042316）を用意した。従来は開発版であるShiretoko Nightlyをベースに計測していたが、リリース版どうしで速さを比べるのも悪くない。また、大多数のユーザーの関心は、Firefox 3と比較してどうかという点に絞られよう。そこで、現時点におけるFirefox 3の最新版をもってきた。 比較対象の第二グループは、Google Chrome（2.0.172.30, A
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (本記事) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (2009/09/07) 先週末IntelのSSD、X25-Mが突然7,000円ほど値下がりしたので、ついに我慢できず手を出してしまいました。初めてのSSD導入です。 SSDのベンチマーク記事は国内・海外問わずたくさんありますが、実際にデータベースを乗せて計測した記事はそれほど多くありません。そこで、先日ご紹介したtpcc-mysqlを用いてベンチマークテストを行ってみました。 データベースサーバ OS ： Windows XP SP3 32bit CPU ： Core2 Duo T7300 2.0GHz (EIST OFF)
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2009-01-12追記 タイトル修正しました。 2009-01-14追記 String.indexOf と RegExp.test のスコアが逆に書かれてていたのを修正しました。 String.match ばかりで、RegExp.exec を使ったことがありませんでした。 ちょっと気になったので色々とベンチマークを取ってみました。 TEST TIMES IE6 Fx3.0 Fx3.1 (JIT) Safari3 Chrome1 (JIT) A. match(/\s*/) vs match(/ */) "aaaaaaaaaaaa".match(/\s*aa\s*/) 1000000 7203 1714 327 2375 2128 "aaaaaaaaaaaa".match(/ *aa */) 1000000 7156 1638 297 2328 2148 B. RegExp.exec vs
2009-11-12 ナビ子記法について追記しました 本文 今日は、amachangさんの記事 http://d.hatena.ne.jp/amachang/20071010/1192012056 を 1mm だけ掘り下げ、IE 以外のブラウザでも document へのアクセスを速くする方法がないか、色々試してみます。 # 記事自体はずいぶん前に書き上げてたけど、公開するの忘れてたんだな。 C系を追加しました。C系は「ネストしたスコープからグローバル変数にアクセスするとどうなるか?」がテーマです。 試したこと 以下は様々な方法で document へのアクセス速度を計測します。 A系では、非日常的な方法で測定し、B系では実際の用法に近い形で測定します。C系では何重にもネストしたスコープから、グローバル変数にアクセスするとどうなるかを測定します。 A系 A0 は、素の document に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
