blog.8-p.info: Facebook の BigPipe と TTI
Posted at 2010/10/22 01:59, Modified at 2010/10/22 03:42 Facebook のフロントエンドは結構かわったことをやっていて、例えば、ログイン後の http://www.facebook.com/home.php には <div id="pagelet_home_stream"></div> みたいな空の HTML があり、その後に <script>big_pipe.onPageletArrive({ … });</script> <script>big_pipe.onPageletArrive({ … });</script> ... と script 要素が何個もならんでいる。 BigPipe: Pipelining web pages for high performance この仕組みは (変数名のとおり) BigPipe と呼
Jiffy Firefox Extension - Documentation
Quick Links: Jiffy Extension Release Notes Jiffy Extension License Install Jiffy Extension Test Jiffy Extension Install Firebug 1.0.5 for Firefox 2 Install Firebug 1.2.0b6 for Firefox 3 Jiffy-Web Javascript Library - Official Jiffy JS library Jiffy-Web Google Group - For discussing the Jiffy library or extension Overview Each time you take a measurement with Jiffy, the measurements are recorded in
forEach色々とベンチマーク - os0x.blog
cho45さんがCodeReposにあげていたJSEnumeratorに付随していたベンチマークでちょっと遊んでみました。 肝心なことを書き忘れていた。はっきりと差が出ているのは、10回のループをさらに1000回ループさせているからで、大抵の場合はどのメソッドを使っても体感できるほどの差は出ないと思います。 jQuery、prototype.js、MochiKit、fLDR、JSEnumeratorなどで使われているforEach関数の速度比較です。recursive eachは一応オリジナルです。 以下、実験ページ http://ss-o.net/jsenumerator/benchmark/10.html http://ss-o.net/jsenumerator/benchmark/100.html 結果 とりあえずWindowsのみmacは後で面倒だか、じゃなくて、windowsと大
IEの気持ち（深入り編） - 最速チュパカブラ研究会
昨日の続きです。昨日の記事がまったくデタラメだとさすがに気まずいので、Invoke が呼ばれてるよ、という事実ぐらいは確かめようと思いました。私はバイナリアンではないのですが、がんばってMSHTMLの中を追ってみることにします。 まず、C++からIDispatch::Invokeを呼んだ場合と、Javascriptから window.document を参照した場合の2つの処理が合流するところを探しました。 ↑ここです。 スタックの中を覗くと、引数が見えます。 window.document の dispid（呼び出したいメソッドのID）である0x47fが確認できます。 では、ここにブレークポイントを仕掛け、amachangのハックをしない状態で、以下のコードを実行してみます。 alert(document); するとブレークポイントがヒットします。 dispid は 0x47f なので、
arguments に対して shift するための考察（をしていたらカッとなって配列変換のベンチマーク） - IT戦記
JavaScript において可変引数を扱う場合 arguments オブジェクトを使います。 function func() { for (var i = 0; i < arguments.length; i ++) { alert(arguments[i]); } }; func(1,2,3) // 1,2,3 を順に表示 そして 可変引数を使うパターンとしては、 すべて可変引数 固定引数と可変引数 の二つに分けることができます。 すべて可変引数 引数が与えられた分だけ同じような処理を行うパターン function add() { for (var i = 0, r = 0; i < arguments.length; i ++) r += arguments[0]; return r; } var r = add(1, 2, 3, 4, 5); 固定引数と可変引数 最初のいくつかの引
peter.michaux.ca - Lazy Function Definition Pattern
Lazy Function Definition Pattern Published August 11, 2007 in JavaScript This article examines a functional-programming design pattern I've been calling Lazy Function Definition. I've repeatedly found this pattern useful in JavaScript especially when writing cross-browser libraries that are efficient at runtime. Warm-Up Problem Write a function foo that returns a Date object that holds the time th
EfficientJavaScript - Dev.Opera - 効率的な JavaScript
EfficientJavaScript - Dev.Opera - 効率的な JavaScript 目次 この文書について 効率的な JavaScript ECMAScript eval や Function のコンストラクタを使うのはやめよう eval を書き換えよう 関数を使いたいなら function を使おう with を使うのはやめよう 性能を決める関数で try-catch-finally を使うのはやめよう eval と with は隔離しよう グローバル変数を使うのはやめよう 暗黙のオブジェクト変換に気をつけよう 性能を決める関数で for-in を使うのはやめよう 文字列は累積スタイルで使おう プリミティブの操作は関数呼び出しより速い setTimeout() や setInterval() には文字列でなく関数を渡そう DOM 再描画と再フロー 再フローの回数をでき
del.icio.usの重そうな処理速度を計測した - koyachiの日記
del.icio.usのclass=postかdesc周辺をGMで何かしたくなったのでやってみたけど遅い。適当な文字列を各ブックマークタイトル前に挿入するGMを書いて、FireFoxで50 entry/page、10回(だけ!)平均で測定してみた。それほど厳密な計測じゃないので計測状態の違いで差はあると思うけど、できる限り近い状態で計測したつもり。 del.icio.us/ui/static/delicious.jsで出てくる$cを普通に使った場合 Start: GM実行可能フェーズ, Loaded: GMで登録したonloadハンドラ先頭, End: GM内処理終了。詳細は後で出てくるソース参照。 [Loaded - Start] [End - Loaded] [End - Start] 1 5719 1172 6891 2 3125 1234 4359 3 2672 1188 3960
XPathって速度的にどうなの? - takememo
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
Algorithm - O(n log(n))より速いsort : 404 Blog Not Found
2006年12月03日01:45 カテゴリMath Algorithm - O(n log(n))より速いsort 404 Blog Not Found:javascript - Array#sortがオレquicksortより遅い!?はちょっとした驚きですが、実はデータの種類さえ限定できれば、builtin sortを出し抜くことはJavaScriptでなくてもそれほど難しくありません。 例えば、ソートしたい対象が密集した整数値で、メモリーがふんだんにある場合には、bucket sortがあります。これを使えば、Perlにおいてすらbuilt-inを簡単に出し抜けます。 % perl bucket.pl 10000 Benchmark: running bucket, builtin, quick for at least 3 CPU seconds... bucket: 3 wallc
video blog ãã¼ã ãã¼ã¸ å¶ä½ it at pj-blog.net
Video Blogãã¼ã ãã¼ã¸ å¶ä½It æ±äººãã¼ã Pcã¦ã§ã ãã¶ã¤ã³ãã½ã³ã³ 販売ãã¼ã ãã½ã³ã³ãã½ã³ã³è³æ ¼ Itãã¼ã ãã¼ã¸ 製ä½ãã½ã³ã³ é販 ãã¹ãã£ã³ã° ãµã¼ãã¹Pc ã»ãã¥ãªãã£It ã¹ã¯ã¼ã«ãã¡ã¤ã³ãã¼ã ãã¼ã¸ å¶ä½ ä¼ç¤¾Web ãã¶ã¤ã³
prototype.jsを10KBにする方法
2006-11-20T14:20:42+09:00 追記 「何者か」に攻撃を受けて、このページの内容が差し変わっていました。あわててバックアップファイルから復旧しました（「何者か」 = 酒……）。 prototype.jsを10KBにする方法の続き（.htaccessをスマートに使う） : 亜細亜ノ蛾 に続きを書きました。合わせてどうぞ。 JavaScript ファイルを圧縮する 正真正銘、Prototype（“prototype-1.4.0.js”）を10キロバイト（10,453 bytes）に圧縮して、しかも（当たり前ながら）動作するようにする方法です。 ──と聞いて真っ先に思い浮かぶのが「各種JavaScriptファイル圧縮サービス」、という人も多いでしょう。 しかし、自分が試してみたところ、例えば/packer/で圧縮したJavaScriptファイルは上手く動作しませんでした（他は
ブラウザ別JavaScript実行速度テスト（ベンチマーク）
ブラウザ／環境別に、どのくらい速度が違うのかを比較してみました。単位はミリ秒 (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
Opera News
Mindfulness, Opera Air Opera Air partners with the Oxford Mindfulness Foundation August 1st, 2025 Hey all, Today we’re thrilled to announce a partnership between Opera Air and the Oxford Mindfulness Foundation, an internationally recognized... AI Opera’s vision: agentic browsers will tackle web inefficiency and unlock massive productivity gains July 31st, 2025 Agentic AI Browsers are here to compl
javascript - element.innerHTML はなぜ速く見えるか : 404 Blog Not Found
2006年10月22日00:55 カテゴリLightweight LanguagesWEB+DB PRESS javascript - element.innerHTML はなぜ速く見えるか 自分でこう書きながら、実は首を傾げていたのだけどやっとわかった。 404 Blog Not Found:WEB+DB PRESS vol.35 pp.57 まず速度ですが、innerHTMLは代入時にHTMLの構文解析が入るので、速度的にはDOM操作が有利です。 期待に反してそうでないのは、404 Blog Not Found:javascript - DOM vs innerHTML benchmark on MacBook Proでの指摘した通り。このあたりはamachangにちゃんと査読してもらった方がよかったのではないか？ InnerHTMLは速くない。速く見えるだけだ。 その証拠として、以下
IT戦記 - 複雑で重くなった JavaScript を超高速化する方法３
8 ヶ月前に setInterval 書き換えのネタで作ったやつ id:amachang:20060104:1136344836 id:amachang:20060114:1137243389 ふと ちょっと設計変えたらすごく速くなる気がして、作り替えてみた。 でも、作ってみたら clearInterval がちょっとだけ速くなったけど、正直そこまで変わらなかった。 でも、設計はきれいになったと思うので公開します。 ダウンロード http://sample.ecmascript.jp/setInterval/setInterval03.js 以前のもファイル化した 最初の失敗作(utf-8だから適当にエンコードして使ってください) 次に作ったやつ、実績はこっちのがある(utf-8だから適当にエンコードして使ってください) 使いかた すべてのスクリプトより前に読み込む <script src
IT戦記 - ベンチマークツール公開
最近 またしても、JavaScript のベンチマークを取らなければならない仕事が来たので、 ツールをキレイにしました。 それを公開します。(ダウンロードは一番下にあります。) 使い方 script タグで benchmark.js を読み込んで、以下のように連想配列の関数群を渡すだけです。 benchmark({ 'ほげほげの計測': function() { ...... }, 'ふがふがの処理の計測': function() { ...... } }); 結果は以下のように表示されます。 *** ほげほげの計測 *** result : 0.0011[ms] *** ふがふがの処理の計測 *** result : 0.111[ms] 表示された秒数は 関数の中身を一回だけ実行する時間です。 関数呼び出しのコストは差し引かれています。 また、FireBug を使っている場合は benc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Open Web Corner: Serving minified JavaScript files with Google App Engine
YUI Library
http://alex.dojotoolkit.org/shrinksafe/