Mac OS X 用バイナリエディタ。 0xED ファイルの中身を詳細を見るのはもちろん、テキストの改行コードをちょっと確認したい時にも役立つ。PNGやJPEGなど画像ファイルのヘッダ情報を見るのにも重宝しそう。 PNGを開くとこんな感じ。 エディタなのでもちろん変...
The JIT inspector instruments generated JavaScript JIT code to record information about how much code has run and how well it was optimized: - How many times individual operations have been executed. - Whether operations executed entirely in JIT code (fast) or as calls into the underlying virtual machine (slow). - Precision of type information inferred for each operation, as used for optimization.
本文 先日 JavaScript を高速化するには、 VM を知る必要があるんだろうと思い、 以下のような発言をしてみました。 とにかく今は 「V8の最適化の恩恵を受けるための JS の書き方」や「ホットスポットを温めて C よりも速い JS を書こう」という釣りっぽいけど釣りじゃない記事を @Constellation さんや @bad_at_math さんに書いていただく必要があるということでした! 2011-10-23 21:53:44 via Echofon しかし、釣り針が小さかったためか、誰も釣れず。。 自分で調べろってことですよね、すいません。。 と思っていたら、先日下記のエントリが話題になりました。 そのものずばり、JavaScript を最適化する話。 mraleph-The trap of the performance sweet spot 先に感想を言うと、これはい
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
Thanks to everyone that attended the jQuery London and London Web Standards meetups this month. As requested, here are the slides from my talks including links to all of the jsPerf tests embedded for each section. Summary In case you missed the talk, the main takeaway from it was the importance of performance-testing your JavaScript and jQuery code (and appreciating performance gotchas you can kee
Editor's Notes\n\n\n\n\n\nテスト時間は早ければ早いにこしたことはない。全部のテスト通すの&a
はじめに iPhoneやiPadなどiOSに組み込まれているmobile SafariでJavaScriptを使ったアニメーションを動かすと動作が遅くなる事があります。 そこで、CSS3のアニメーションを利用して軽快なUIを実装しようという風潮が高まっているのですが、実はすべてのCSS3アニメーションがmobile safariで軽快に動くという訳ではないようです。 CSS3のアニメーションが軽快に動く(と言われている)理由 結論からいうと、safariというソフトウェアの力だけでなく、iPhoneやiPadのハードウェアの力を借りられるからです。 そういった、ハードウェアのことをアクセラレーターと呼ぶようです。詳しくは参考ページをご覧ください。 ※参考 Hardware acceleration – Wikipedia, the free encyclopedia アクセラレータとは
JavaScriptのパフォーマンスのボトルネックを解消するテクニックとアプローチを解説します。実行時間、ダウンロード処理、ページのライフサイクルなどJavaScriptの様々な部分に対応しながら、DOMへのアクセス、ネットワークのレイテンシ、JavaScriptの同時ダウンロードのブロッキングなど、高速なJavaScriptエンジンであっても最適化できない部分をもカバーしています。本書で述べられているテクニックとアプローチは、パフォーマンスを向上する上で重要であるだけでなく、今後低レベルなJavaScriptの実行時間が短縮されていくにつれて、さらにその重要性は増していくでしょう。 はじめに 1章 読み込みと実行 1.1 スクリプトの配置 1.2 スクリプトのグループ化 1.3 ノンブロッキングなスクリプト 1.3.1 スクリプトの遅延 1.3.2 動的なscript要素 1.3.3 X
自分が書いたJavaScriptのコードスニペットに対してどのコードが早いのかベンチマークを比較することができるWebサービスであるjsPerfの紹介と使い方。JavaScriptでは同じ機能を実現するための方法は様々であり、どのコードが優れているのかを調べる方法としてプロファイラなどを利用することがあります。しかし、JavaScriptはブラウザ毎によっても速度が変わることが多いため、ブラウザ依存のツールだと比較しにくくなるため、ブラウザ上でテストコードを実行し、それらのベンチマークを簡単に記録、比較できるサービスがjsPerfです。 jsPerfの比較方法 jsPerfの内部ではBenchmark JSというベンチマークライブラリが使用されています。(jsPerfの運営者が作成している) jsPerfの計測方法は一定時間内にどれくらいコードスニペット部が実行できたのかで比較します。その
転勤・単身赴任というライフ・イベントがあり、すっかり更新が止まっていましたが、前回 に続き、「Rendering: repaint, reflow/relayout, restyle」から後半のレンダリング負荷を測るツールの使い方をお届けします。記事中の リフロー や リペイント といった用語は、前回記事「用語の定義」 を参照してください。 元記事は初稿が2009年12月でツールのバージョンも古いため、現時点の最新バージョンで記事を再構成しています。また実行環境によって観測結果が異なるため (非力なマシンの方がレンダリング負荷の割合が高いけど、サンプルとしては分かりやすい)、以下に本記事で試した環境を記しておきます。 dynaTrace AJAX Edition バージョン:Version: 2.1.0.603, built on 2010-12-15 ブラウザ、PC:IE8 / Wind
ARMはスマートフォン・携帯電話で広く使われていますが、クロック周波数の割に微妙にIntelのCPUよりも遅く、なんでなのかなーということで調べてみました。 まず、http://www.coremark.org/benchmark/index.php のベンチマークの結果から、色々数字があり、すごく悩みながら信用できそうな数字を拾ってみました。 1コア当たりの性能 名称 性能 備考 ARM Cortex-A8 600Mhz 2.035/MHz Cortex-A8は2010年のスマートフォンの主流 NVIDIA Tegra 250 1GHz 2.646/MHz Cortex-A9は2011年のスマートフォンの主流かな? Intel Core2 Duo 1596MHz 3.205/MHz Intel Core i5-650 3200MHz 3.244/MHz このように、クロック当たりの性能が
Brandon Aaronの2009.6.24のエントリ Understanding the Context in jQuery jQuery1.3時代に書かれた内容だが賞味期限は切れていない Selectors API(ex.$("a"))などで検索範囲を絞り込むために使う第二引数("Context")の誤用が多い 正しく理解しないと、パフォーマンスアップというご利益は得られないとレクチャー コメント欄では、高速なセレクターの使い方がtest方法付きでレクチャー $("#main","#top");//この書き方は、contextを指定(変更)できていない。 以下斜め読んだ内容 context jQueryで要素指定するときのオプションとして提供。 これ使うと、要素の検索範囲を制限できる ex. div#naviの中のa要素だけを取得 contextはDOMツリーが巨大なページのときは威
CSS Sprites 化や画像サイズの最適化、Data URI 化、CSS/JavaScript ファイルの圧縮・結合・読み込み順番の整理やキャッシュ制御など、本サイトでは主に HTTP リクエストの数、データ量およびそれらの順番に関して色々なテクニックを試してきましたが、さらに深く掘り下げるには JavaScript の実行がページの読み込み時間に与える影響を知っておく必要があると思います。 「ウェッブサイトの表示速度を測定するフリーツール集」 でも紹介しましたが、dynaTrace AJAX Edition という優れたツールをフリーで公開している dynaTrace software のブログでこの問題を扱った記事がありましたので共有します。JavaScript 高速化 Tips は (例えば 「JavaScriptを高速化する6つのテクニック」 など) 多々あるかと思いますが、ペ
2011年2月21日 追記 $script も新規参戦してきました。高々 643 バイトで、非同期読み込みや依存性の制御などができるそうです。いずれ紹介したいと思います。← 「新参の超軽量JavaScript非同期ローダー3種を徹底比較」で紹介しました! これらのローダーのうち、LABjs の作者が 「On Script Loaders」 で HeadJS と ControlJS について意見をしていて、面白そうです。そのうち日本語訳や各ローダーの比較を行ってみたいと思います。 ローディング・スクリプトをめぐる議論 さてさて、本エントリーの本題は前述のローダーではありません。「Prefer asynchronous resources」 や Google Analytics のスニペット に示されているような、ローディング・スクリプトの変遷をまとめてみます。 これらのスクリプトのごく初期は
Windows Internet Explorer 9 IE9開発版の最新版となるIE9 Platform Preview 7が公開された。IE9 PP7における最大の特徴はJavaScriptエンジンの調整が実施され、実際のWebサイトやWebアプリケーションにおけるJavaScriptの実行がより高速化された点にある。すでにベンチマーク試験としての意味はないとしているが、SunSpiderを使ったベンチマークでベータ版も含めた主要最新ブラウザで最速をマークしたことが紹介されている。 HTML5, and Real World Site Performance: Seventh IE9 Platform Preview Available for Developers - IEBlogには、ほかのブラウザとIE9 Test Driveに追加された新しいデモを実行した比較動画が掲載されてい
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く