スマフォブラウザゲームのパフォーマンスチューニング手遅れパターン - latest log
最近、こういう事例が増えてます ネイティブゲームアプリもグリグリアニメーションする昨今 🐤俺らもブラウザゲームの限界を目指そうぜ! 🐤盛るぜー盛るぜーー超盛るぜーー 数ヶ月後… 🐤来月リリースだけどカクカクします助けてーー 🐲きさまら何度やったらわかるんだ…そこに正座しろ…(ゴゴゴゴゴ) #こうですか?— コラーゲンたっぷりさん (@uupaa) 2014, 8月 19 🐲なぜ作ってる途中で実機で動作確認をしなかったんですか? 🐤え、あの、CreateJS なら大丈夫かとおもって… 確認してませんでした 🐲(イラッイラッ #こうですか— コラーゲンたっぷりさん (@uupaa) 2014, 8月 19 🐲(はぁ…)とりあえず実機動作とコードを見たいので開発サーバ名やログインする為の情報ください …2日後… 🐤…これで💦 🐲…動かない…あとminify解除してない状態な
JavaScript(V8)で避けるべき(だった?)クロージャの使い方 - kazuhoのメモ置き場
Grokking V8 closures for fun (and profit?) に、ほんの少しだけ触れられている話なんですが。 ごく最近まで V8 には、オブジェクトリテラルの中で関数リテラルを使った場合に非常に遅くなる(というかGCが多発する)問題があった。 たとえば、 function doit() { for (var i = 0; i < 1000; ++i) { for (var j = 0; j < 1000; ++j) { var o = { f: function () { return i + j; } }; } } } doit(); というコードを node-0.6.19 で実行すると、以下のように mark-sweep GC が大量に発生して処理に時間がかかっていることが分かる。 $ time /usr/local/node-0.6.19/bin/node -
Twitterがページ表示時間を5分の1に高速化。どのようなテクニックを使ったのか？
Twitterがフロントエンドのアーキテクチャを見直し、Webページの読み込み速度を改善したことをブログで明らかにしています。 新しいアーキテクチャでは、これまでWebブラウザ上でJavaScriptの処理によって行ってきたWebページのレンダリングを見直し、サーバ側でレンダリング済みのHTMLページを送信し表示することにしています。これによってWebページの読み込みから最初のツイートの表示までの時間が大幅に短縮されることになりました。 When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’
ローカルストレージに簡単な解決策はない
原文：“There is no simple solution for local storage” (on March 5, 2012 by Chris Heilmann) 要約：私たちは良いデータストアとして localStorage を推奨するのをやめなければならない。パフォーマンスがひどく損なわれるからだ。しかし残念なことに、代わりとなるものはまだ完全にサポートされておらず、また簡単に実装できるものでもない。 Web 開発において、うますぎる話に出くわすことは常々だ。そういったもののいくつかは良いもので、だからこそそれが「すべて」として目立ってしまい、開発者を使うように仕向けてしまう。しかし、多くの場合、良いと思われていたものはそこまで良いものではない。また、しばらく使ってみてはじめて「間違っていた」と気づかされるものなのだ。 そんなもののひとつに、localStorage がある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNA Engineering - DeNAエンジニアのポータルサイト
