2009-11-12 ナビ子記法について追記しました 本文 今日は、amachangさんの記事 http://d.hatena.ne.jp/amachang/20071010/1192012056 を 1mm だけ掘り下げ、IE 以外のブラウザでも document へのアクセスを速くする方法がないか、色々試してみます。 # 記事自体はずいぶん前に書き上げてたけど、公開するの忘れてたんだな。 C系を追加しました。C系は「ネストしたスコープからグローバル変数にアクセスするとどうなるか?」がテーマです。 試したこと 以下は様々な方法で document へのアクセス速度を計測します。 A系では、非日常的な方法で測定し、B系では実際の用法に近い形で測定します。C系では何重にもネストしたスコープから、グローバル変数にアクセスするとどうなるかを測定します。 A系 A0 は、素の document に
Try It Out Click "Run Tests" to see how the scope of a variable affects performance in this browser. (view the source for details) is a lightweight tool for creating ad-hoc JavaScript benchmark tests. Features include ... Single-file install (JSLitmus.js) Works on Firefox, Opera, Safari, IE, Google Chrome, and iPhone browsers Adaptive test cycles - tests take ~1-2 seconds, regardless of the operat
ErlangとPerlの速度比較の文字コード変換部分に関して， Danさんからトラックバックをいただいたので再度測定してみた． そもそもはじめからUTF-8、それもutf8フラグがたっている文字列にfrom_toを使うのはばかげている。 とのことだけど，utf8フラグは立っていない想定． use utf8 は罠がいっぱいな割にメリットが少なく，普段は使用しないので・・・． （DBIが未対応だったり，モジュールによってフラグの扱いが違ったり（YAML::*とか）なので） また，多くの場合は，ファイルやソケット等からUTF8バイト列を受け取って，それを利用することになるので， utf8フラグ無しの文字列からの変換で比較する方が実際の利用状況からもフェアではないかと感じるけれども． （ただ，バイト列にしたとしても，やっぱりEncodeが一番速かった） そんなわけで，コードは以下のように修正． m
ref:404 Blog Not Found:perl tips - Encodeを速く使う方法 当然の話だけど、対象の文字列が長くなると、Encode::encode も、$e->encode も大差ない。 ちょっといじって試してみる。 use strict; use warnings; use Benchmark qw/cmpthese timethese/; use utf8; use Encode; use Jcode; use Unicode::Japanese; use Smart::Comments; my $str = join '', ( 'a' .. 'z', ( map { chr } ord('ぁ') .. ord('ん') ) ); $str = $str x shift if @ARGV; my $bytes = encode_utf8($str); my $u
Erlangは並列処理が得意なので，それに関しては他の言語より圧倒的に速いのは確認したけれど， わたしがよく使う通常の処理に関してもどの程度違うのか測定してみた． 一般的な処理に関しては，The Computer Language Shootout Benchmarks にたくさん結果があるので，そちらが参考になる． 言語としては，どちらも動的型付けで，コンパイラで内部表現に直してからインタープリタで実行，というあたりは一緒． （ただしErlangはnativeコンパイラが別途ある） ほぼ同じくらいの速度が出ても良さそうなところ． Perlの代替を考えていたので，比較対象はPerl． Language Shootout によれば，Erlang の方が多くのテストで２～３倍前後高速．nativeコンパイルすると，その差がさらに広がる感じ． Erlang 5.5.4 と Perl v5.8.5
以前、セッション管理に向いているデータベースは MySQL ? Oracle ? という記事で Oracle と MySQL のパフォーマンス差について書いたことがありますが、新年度の技術開発に向けてまた改めて検証をしています。世の中いろいろな事情で 商用 DB を使っている人は大勢いるでしょう。Oracle を使ってセッション管理をする必要だってあるかもしれない。 と言うわけで今回は、Oracle でセッション管理するならどうする？編です。比較対象として MySQL でのパフォーマンスも計測しています。Oracle とか MySQL は実行環境でパフォーマンスが結構異なるので、一応検証環境はこんなかんじ。 検証マシンスペック VMware 6.0.6000 上に構築した raw-disk タイプの仮想環境 Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz mem
ref: qsort - enbug diary (2007-02-10) ふむふむ、NetBSD 由来の qsort が速いと。unsigned int の要素数 10,000,000 で試してみた。表中の数字は所要時間で単位は秒。 まず、Pentium M 2GHz の coLinux on Windows の gcc-4.0 で、 コンパイルオプションは -O2 だけ。 ランダム ソート済み 逆順ソート済み 大体ソート済み qsort 5.08 4.29 4.45 4.05 pgsql 4.36 0.06 0.06 2.91 qsortG 3.29 1.70 1.81 2.11 STL 1.78 0.70 0.74 0.74 同じマシンの Windows で VC2005 で /O2 で コンパイル。 ランダム ソート済み 逆順ソート済み 大体ソート済み qsort 4.547 1.
id:quaa:20060306#p1を見て、ループを回して要素にアクセスしたときに速度がどうなのか気になったので調べてみた。 スクリプト <html> <body> <script type="text/javascript"> function x(exp, type) { return document.evaluate(exp, document, null, type, null); } var result = {}; Function.prototype.time = function (s) { var func = this; result[s] = [0]; return function() { for (var i = 0; i < 10; i++) { var start = new Date().getTime(); var r = func.apply(thi
JavaScriptの文字列連結はすればするほど長くなればなるほど重くなるっていうのは有名な話でどうしても何回も連結せざるを得ない状況(テンプレート処理)では以下のような俺オブジェクトを使って対処してきました。 ただ人間欲が出てくると replace したいとか length 取得したいよ...と思い、自分で実装する必要が出ていました。ただ String.prototype が継承できるのを思い出し作り直したのが以下のもの。 function Buffer() { var k = -1, b = []; this.append = function() { for(var i=0,f=arguments.length;i<f;i++) { if(!arguments[i]){ return; }; b[++k] = arguments[i]; }; }; function toString
ブラウザ／環境別に、どのくらい速度が違うのかを比較してみました。単位はミリ秒 (msec) になっています。いくらか誤差がありますので、あくまでも参考程度にしてください。WinXPはIE6とIE7を入れた別々のハードディスクを装着して計測しています。 以下の表の文字のリンクをクリックすると、スクリプトが実行されます。 JavaScript / Ajaxプログラムを作成する際の参考にしてみてください。 Firefox 2 vs 3.0RC1のベンチマークも用意しました。 MacOS X (Tiger) vs Windows (XP SP2) のベンチマークも用意しました。 最終更新日 : 2008/5/19 openspc@po.shiojiri.ne.jp ■機種スペック Windows XP, Celeron 2.8GHz, RAM : 512MB MacOS X Tiger, Powe
Perl で YAML と JSON のベンチマーク比較 YAML や JSON が軽い！速い！と言われているが、どれくらい速いのか Perl モジュールでベンチしてみた。 ※個人的に興味があったのがデータの読み込み (Load) だけだったので、データの書き出し (Dump) はテストしていない。 結果的には、YAML と 比べて JSON の方が 6倍〜8倍高速。ただし、これはデータ量が少ない場合で、データ量が大きくなると 0.5倍〜0.8倍 と差が縮まってしまう。 また、YAML::Syck と JSON::Syck で比べると、データ量にかかわらずその差は数パーセント程度になってしまう。 ちなみに、Data::Dumper でダンプしたデータを eval したものとも比べてみたが、YAML を基準にすると eval は約50倍速く、YAML::Syck (と JSON::Syck)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
