吉川徹さん（@yoshikawa_t）の「DOM操作の最適化によるJavaScriptチューニング」問題解説記事 #javascript｜CodeIQ MAGAZINE
吉川徹さんによる「DOM操作の最適化によるJavaScriptチューニング」問題解説記事です。JavaScriptのDOM操作について基本的なパフォーマンスチューニングができるかどうかを評価する問題でした。 チューニングを行うことで、具体的にどういった形のコードになるかを中心に解説していただきましたので、ぜひ参考にしてくださいね！ by 馬場美由紀 （CodeIQ中の人） 吉川徹です。 少し前になりますが、私の方から以前、JavaScriptのパフォーマンスチューニングについての問題を出題しました。今回は、その問題の解説をしていきたいと思います。 また、この問題は、HTML5 Experts.jpとの連動企画となっており、こちらの記事を読んで頂くとおおよそのチューニング方法について理解できるというものになっています。ぜひ、合わせてご覧頂ければと思います。 問題文 あるHTMLファイルに記述
JP Morgan Chaseがデリバティブ専用スパコンをFPGAで作った話 #fpgax - スティルハウスの書庫の書庫
金融系でFPGAというとHFTへの応用が知られてるけど、この事例はリアルタイムトレードの話ではない。金融業務で必要とされるバッチ処理やHPC（High Performance Computing）でもFPGAが本格的に使われ始めてるという話だ。 元ネタは、2011年にJP Morgan Chaseの人がスタンフォード大学で講演した内容。このビデオを見ていたらとっっっても面白かったので、 #fpgax 第3回で使う資料として要点を訳し、俺のコメントや補足を追加してみた。 http://www.youtube.com/watch?v=9NqX1ETADn0 （スライドはこちら） なお、FPGAも金融も素人なので、勘違いや誤訳があるかもしれない。FPGAとは何かよく知らない人はこちらをどうぞ。 リーマン・ショック対策のスパコン開発 JP Morgan Chaseは、社債やモーゲージ（不動産を担保
High Performance Web Frontend
★追記： https://speakerdeck.com/ahomu/high-performance-web-frontend-2013-qiu のほうがブラッシュアップ版です WCAN 2013 Summer (7/6) で行われた、"High Performance Web Frontend"のセッション資料です。Network 1 : Render 2 : Compute 1 くらいの割合で、各パフォーマンス要因についてお話しました。
今すぐ使える『明日からつかえるシンプル統計学』
まちがえるな、統計学は道具だ。統計は学ぶものではなく、使うもの。 これはわたし自身への戒言。だから、使い方を誤らない程度に理解していればいいし、そのために教科書をイチから読み込む必要も、Rをマスターする必要もない。もちろん様々な武器（統計手法）が使えるに越したことはないが、次のような問題と向き合っているなら、本書をオススメする。 あと500人お客を呼び込むためには、いくら広告費が必要か？ カスタードケーキがチョコパイに勝つには、「味の改良」と「販促キャンペーン強化」のどちらが有効か？ クラス全体の成績が低迷している。国語と数学の両方が苦手な生徒だけ補習したほうがいいのか、全員に国語の補習をしたほうがいいのか 前任者から引き継いだデータが大量にあるが、それぞれの関係や着眼点がまとめられてない。どこから手をつければいいか？ 社内のKPI（Key Performance Indicator :
High Performance JS heatmaps - Codeflow
You can draw around 500'000 individual data points per second in realtime. Around 10'000 per frame are no problem. The way it works is that points to draw are recorded into a position buffer (10k points) and when you call heatmap.update() (or when the buffer is full) it draws these points with WebGL by additively blending them into an off-screen floating point texture. QualityThe heat is updated/r
ウノウラボ Unoh Labs: mod_expires と mod_rewrite を使ってウェブサーバへのアクセスを減らす方法
最近、雨の日が続いて自転車通勤ができていない naoya です。 今日は、先週ぐらいからフォト蔵に導入した Apache で mod_expires と mod_rewrite を使ったウェブサーバへのアクセスを減らす方法を紹介します。 通常のウェブサーバは、更新されていないリリースに対してアクセスすると、ステータスコード 304 とIf-Modified-Since ヘッダをつけて応答データを返しますが、CSS や JavaScript など比較的更新頻度の少ないファイルに対して、毎回応答を返すのはウェブサーバから見ると無駄なアクセスです。 Apache の mod_expires と mod_rewrite を使うと、この無駄なアクセスをブラウザキャッシュを有効活用にすることにより、静的なファイルに対するアクセスを減らすことができます。 まず、仕組みから説明すると、とても単純で mod
How To Write Fast, Memory-Efficient JavaScript — Smashing Magazine
There are many common pitfalls when it comes to writing memory-efficient and fast code. In this article we’re going to explore some test-proven approaches for writing code that performs better. JavaScript engines such as Google’s V8 (Chrome, Node) are specifically designed for the fast execution of large JavaScript applications. As you develop, if you care about memory usage and performance, you s
JSX はなぜ「速い」のか - kazuhoのメモ置き場
なぜ「速い」のか、について JSX 開発者の立場から。 たとえば、シューティングゲームで一番重たい処理は何か。言うまでもなく衝突判定。多数の弾や敵機の衝突判定を毎フレームごとに行う必要があり、この演算が重たい。 JSX に同梱されている web/example/shooting.jsx には衝突判定のコードが複数あるが、一番重たいのは Bullet#update 関数で、その処理は以下のようになっている*1。 for (var rockKey in st.rocks) { var rock = st.rocks[rockKey]; if (this.detectCollision(rock)) { if (rock.hp == 0) return false; inDisplay = false; if (--rock.hp == 0) { st.score = Math.min(st.s
jQuery を高速に使う CSS セレクタの書き方 - てっく煮ブログ
JavaScriptjQuery は CSS セレクタで要素を選んで処理できるのが魅力的ですね。そんな jQuery ですが、CSS セレクタの書き方次第で速度が大幅に変わってきます。ここでは jQuery の内部処理を疑似コードで示しつつ、jQuery を高速に使うためのポイントを５つに絞って紹介します。何度も同じセレクタを実行しないクラスだけを指定するのは禁止#id を積極的に使う途中までの結果を再利用する子供セレクタ(>)を使うと速くなることがある※ この記事は jQuery 1.2.6 のソースコードを元に記述しています1. 何度も同じセレクタを実行しない改善前 // 例題 1 $("div.foo").addClass("bar"); $("div.foo").css("background", "#ffffff"); $("div.foo").click(function(){
IT戦記 - 一行で IE の JavaScript を高速化する方法
以下の一行をすべての JavaScript の前に読み込む /*@cc_on _d=document;eval('var document=_d')@*/ この一行を読み込むことによって IE での document へのアクセスが 5 倍速くなります。 たとえば 以下のように、読み込む前と読み込んだ後を比較してみます。 // Before var date = new Date; for (var i = 0; i < 100000; i++) document; alert(new Date - date); // 643 /*@cc_on _d=document;eval('var document=_d')@*/ // After date = new Date; for (var i = 0; i < 100000; i++) document; alert(new Date -
MongoDBとメモリ使用量
はじめに WAF「Scutum（スキュータム）」ではサービス開始時より、データストアとしてmemcachedとpgpool II+PostgreSQLを利用しています。これらはどれも安定して動いており満足しているのですが、最近になってより柔軟にデータを取っていきたいというニーズが高くなってきたため、MongoDBの導入を行いました。まだ完全なリプレースまでは至っていませんが、元々のデータベースのスキーマ構造がシンプルであることもあり、数ヶ月以内にはpgpool II+PostgreSQLの部分をMongoDB（Replica Sets）で置き換えることができるのではないかと思っています。 MongoDBにとっての「メモリ使用量」 MongoDBを導入するにあたり、Linux(X86_64）上でMongoDBを動作させたときのメモリの消費について、簡単にですが調べてみました。まず参考にしたの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【これは便利】あなたのWebサイト表示のどこが遅いかを一発で調べるブックマークレット | 初代編集長ブログ―安田英久
1216彩票-官网平台
http://www.eecs.tufts.edu/~dsculley/papers/large-scale-rank.pdf