タグ

2013年7月10日のブックマーク (5件)

  • WebWorkerでXMLHttpRequest - Qiita

    XMLHttpRequestをWebWorkerで実行する Senchaが公開したHTML5のFacebookクライアント、Fastbookの高速化手法として、 XMLHttpRequestをWebWorkerで実行するのがあるそうです。 ということで、実際にやってみました。 WebWorkerの呼び出し jQueryを用いた環境で使いやすいように、jQueryの$.ajaxインターフェイスに似せています。 ただし、XMLHttpRequestをWebWorkerからは取得できないので、全く一緒ではありません。 ExecutorServiceの実装 WebWorkerを大量に作成すると負荷がかかるので、 少し手間ですが、同時実行数を制限し、リクエストをキューイングする ExecutorServiceを実装します。 var ExecutorServece = (function() { Ex

    WebWorkerでXMLHttpRequest - Qiita
    kyo_ago
    kyo_ago 2013/07/10
  • JavaScript : localStorage と IndexedDB : typeOf 'aki_mana'

    localStorage のパフォーマンスについて考察したブログエントリがhtml5jのMLで紹介されたので読んでみた。 現在、JavaScriptコードのインストーラとして活用してるので、気になった次第。 *** localStorageのパフォーマンス問題を再び考えてみる http://www.nczonline.net/blog/2012/04/25/the-performance-of-localstorage-revisited/ まとめとしては、「あんまり気にすんなよ、でも、でかいデータを保存するのはNGな」って感じでした。 リンク先(NCZOnline)も読んだら、「同期的に呼び出すので、大きなサイズだと、JavaScriptの他の処理が止まる」という事が書かれてた。まぁ、紹介されてる通り、でかいデータ保存はNGということ。 冒頭で述べた通り、インストーラに使ってる体験談を:

    JavaScript : localStorage と IndexedDB : typeOf 'aki_mana'
  • WebWorkerのデバッグ - 音の鳴るブログ

    WebWorker は便利だけどデバッグしにくい。僕は根っからのプリントデバッガーなんだけど、WebWorker は console.log が使えなくて困る。しかし泣いてばかりもいられない。 WebWorker で console.log を使う WorkerConsole というやり方がある。下記は簡略版だけど、WebWorker側に console というグローバル変数を用意して、log とか error メソッドで呼び出し元に引数を postMessage する。そして、呼び出し元の onmessage でコンソールに表示する。 このやり方には若干問題があって、postMessage を通過出来るものしか表示できない。つまりオブジェクトを表示して DevTools で属性を確認したりとかできない。 // worker.js global.console = {}; ["log",

    WebWorkerのデバッグ - 音の鳴るブログ
  • HTML5Experts.jp

    進化するWeb ~Progressive Web Appsの実装と応用~(de:code2018より) 物江 修 2018年5月に開催された日マイクロソフト主催のイベントde:code 2018で「進化するWeb ~Progressive Web Appsの実装と応用~」というセッションを担当しました。 イベントに参加できなかった...

    HTML5Experts.jp
  • node.js と thread hog の話(3)

    [前回までの話へのリンク] ・node.js と thread hog の話(1) ・node.js と thread hog の話(2) では、なぜ今頃になって HTTP Server の c10k 問題(もしくは、thread hog 問題)が顕在化したのだろう。 当時(90年代の終わり頃)と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB~8MB のスタック領域を仮想メモリ空間に確保しなければならな