Web Platform Dive into the web platform, at your pace.

メモリーリークに近い話とは思いますが、ちょっと毛色の違う内容です。 「JavaScript がメモリーを馬鹿食いしてどうしようもない…」 「なぜかメモリーが確保されっぱなしなんだけど…?」 といった状況の解消法。 JavaScript にはガーベッジコレクタがあるから大丈夫… と、思われがちですが、ガーベッジコレクタは『本当にメモリ解放が必要になるまで何もしない』というものです。 (状況が悪いとガーベッジコレクタは何もしてくれなくて、ブラウザが固まってしまいます。。) 「コストはかかるが、信用できないならプログラマが勝手にやってしまえ!!」という感じです。 削除候補のメモリを強制解放 ── CollectGarbage() 関数 ── 解放したいタイミングで window.CollectGarbage() を走らせることで、強制的にメモリを解放できます。 // IE 以外のブラウザ対策のた
有給を駆使し一足早くクリスマス休暇に突入、ヒャッホイ Ingress やるぜーと 意気込んでいた矢先ノロウイルスにやられダウンした。かなしい。鎮まれ俺の胃袋・・・ そんな腹痛日和の気晴らしとして今日は Garbage Collection Advent Calendar に参加してみることにしました。 Advent Calendar 初体験につきよくわかってないけど勝手に参加していいんですよね? GC というとジェネレーショナルだのパラレルコンカレントだのといった話が目立ちがちだけれど、 現実の問題というかブラウザを相手にするとそれ以外の細々とした面倒が目につく。 GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の1つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理
前に見た時に理解できずにいた2chスレを備忘録としてコピペ。 時間あったら整形する。 + JavaScript の質問用スレッド vol.52 + 元々のスレ:http://pc8.2ch.net/test/read.cgi/hp/1161422792/ 過去スレ保管庫:http://wing2.jp/~mirrorhenkan/2ch/javascript/read.php/1161422792/ 670 名前:Name_Not_Found[sage] 投稿日:2006/11/24(金) 11:42:28 ID:??? >>666 自分でそういう関数を1行で定義して使うのはいいんじゃねの? >>669 setAttributeダサイ! >>667 ホレ。 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html><head><tit
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
[ajax][javascript][はてブ] はてブの「ブックマークの確認」ページは、IEでメモリリークする! IE のメモリリーク調べる為の「Drip」ってツールが ここにあって、 このツールは単純にリークしそうなコードチェックしたり、 オートリロードして、外部から参照したメモリ使用量を記録してくれるだけなんだが はてブの追加ページで確認するとこんな感じになる。 (オートリロードなんで負荷高くなるから、悪用したり、やりすぎたりしないようにw) タスクマネージャー等の、外部から参照したメモリが増えているからといっても OSがアプリケーション用にキャッシュしているメモリが増加しているだけの 可能性があるから、一概に鵜呑みはできないんだが 平均して1回のリロードに 1M 近く増えていくとかおかしい。 (MicroSoft もタスクマネージャーで確認しろっつってるし) IE単独だと、閉じた時点
Justin Rogers Microsoft Corporation June 2005 日本語版最終更新日 2006 年 2 月 3 日 Web 開発者の進化 以前は、メモリ リークは Web 開発者にとって大きな問題ではありませんでした。ページは比較的単純に保たれ、サイト内の異なるロケーション間のナビゲーションは解放されたメモリをクリーンアップするうえで優れた方法でした。リークがあった場合も、たいていは気付かないほど小さなものでした。 新しい Web アプリケーションは、より高い標準に従います。ページはナビゲートされずに何時間も実行され、Web サービスを通じて更新情報を動的に取得する場合があります。複合イベント スキーム、オブジェクト指向の JScript、およびアプリケーション全体を生成するためのクロージャを組み合わせることで、言語機能が限界点に達します。これらの変更およびその他
IE でのメモリリーク ちょこちょこと紹介されているので知っている人も多いと思うが、IE には DOM ノードに絡んだメモリリークの問題がある。これに関しては Microsoft 自身の記事である「Understanding and Solving Internet Explorer Leak Patterns」に詳しいが、簡単にいえば DOM ノードオブジェクトに関する循環参照を作ると、IE を終了させるまでそのオブジェクトが解放されないというものだ。記事によればメモリリークには以下のようなパターンがあるという。 1. 単純な循環参照 ある DOM ノードオブジェクトのプロパティをたどっていくと自分自身に行き着く場合。以下のようなパターンが考えられる。 element.property == element element1.property1 == element2, element2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く