参考にしたのはココ。IEのメモリリーク問題DOM オブジェクトとメモリリーク: Days on the Moon Internet Explorer 繝ェ繝シ繧ッ 繝代ち繝シ繝ウ繧堤炊隗」縺励※隗」豎コ縺吶k Googleさんに「IE メモリリーク 循環参照」で聞いた結果の上3件ってだけやけど・・。 「念のため」も含めてやったのもあるので全部が効果あったのかはわからないが、俺が気をつけたポイントは以下の通り。 DOMオブジェクトは生成後すぐにDOMツリーに追加する今まではcreateElementして、スタイルやイベントハンドラ設定した後で親ツリーに追加してた。これを生成後すぐにツリーに追加し、スタイルやイベントハンドラはその後で落ち着いてやるように変更した。 //↓こんなのを var img = document.createElement('img'); img.onmousedown
今日はIEのメモリリーク対策に注力した - SEの行き着くところ…の続き。ついについに解決した。解決の糸口(というか答え)はPrototype.jsにしっかりと書いてたやんか! // avoid memory leak in MSIE: clean up this.transport. onreadystatechange = Prototype.emptyFunction; どうやらDOMオブジェクトだけでなく、new ActiveXObject('Msxml2.XMLHTTP')もメモリリークする模様。(確かに考えてみりゃそっちの方がリークしそう・・) ここでポイントだったのはonreadystatechangeに「null」を入れても効果がなく、関数外で定義された(できればグローバルスコープの)空関数を定義する、というところやった。(上のコードでいうとPrototype.emptyF
Archived MSDN and TechNet Blogs 2/7/2020 2 minutes to read MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. Archived blogs are grouped alphabetically by the initial letter of the blog name. Blogs and blog posts can be searched by their names, using the Search box at the top of the page. Actively updated blogs have been moved to other blog sites,
IE6のベンチスコアを追加 補足を追加 アイコンやウインドウをつかんでずずっと移動する。 この動作をもっともっとスムーズにするために、何ができるか考えてました。 以下はサンプルコードです。 uuClass.MyDrag = uuClass.Generic(); uuClass.MyDrag .prototype = { construct: function() { // ウインドウを包括するオブジェクト this._frame = uu.id("WindowFrame"); // ウインドウのタイトル部分でmousedownされたらhandleEventを呼び出す。 uu.event.set(this, uu.id("WindowTitle"), "mousedown"); }, handleEvent: function(evt) { uu.event.stop(evt); // イベ
こういう泥臭い資料作りもやってるので、一応書き残します。 問題1. array.length へのアクセス var ary = new Array(100000); な配列があるとします。 IE6環境下で、配列の長さを求める方法を、早い順に並べてください。 TEST1. a.length; TEST2. var L = "length"; a[L]; TEST3. a["length]"; 正解は、TEST1 < TEST3 < TEST2 です。 Browser TEST1 TEST2 TEST3 総評 Chrome 1 1 1 全て同じスコア Safari 1 2 3 TEST2はTEST1の2倍, TEST3に至っては3.4倍スコアが違う Opera9.27 1 1 1 全て同じスコア Opera9.6β 1 2 2 1.3倍スコアが違う Firefox2 1 2 1 TEST1とT
日本Javaユーザーグループ 概要 JavaScriptの誤解 重くしている犯人 プロファイラ JavaScriptの誤解 JavaScriptは遅い 速いです 重くしている犯人 DOM DOMをフェーズに分けて考える JavaScriptとコンポーネント(C++)との通信(取得) DOMノードの追加、値の変更 スタイルの計算 レイアウトの計算 JavaScriptとコンポーネント(C++)との通信(取得) XPConnectやCOMとの通信 単純なプロパティアクセスの数十倍(IE以外は無視しておk) COMは重い 通信回数=DOMのオブジェクトの「.」の数 DOMノードの追加、値の変更 取得の場合と同じ「.」の数 ノードに変更したというフラグが立つ parent.appendChild(child)だとparentとchildにフラグが立つ。 重要:再計算がJavaScriptの実行後に
2006年03月06日 Ajaxにおけるメモリリークの注意点 [ajax][javascript][はてブ] はてブの「ブックマークの確認」ページは、IEでメモリリークする! IE のメモリリーク調べる為の「Drip」ってツールが ここにあって、 このツールは単純にリークしそうなコードチェックしたり、 オートリロードして、外部から参照したメモリ使用量を記録してくれるだけなんだが はてブの追加ページで確認するとこんな感じになる。 (オートリロードなんで負荷高くなるから、悪用したり、やりすぎたりしないようにw) タスクマネージャー等の、外部から参照したメモリが増えているからといっても OSがアプリケーション用にキャッシュしているメモリが増加しているだけの 可能性があるから、一概に鵜呑みはできないんだが 平均して1回のリロードに 1M 近く増えていくとかおかしい。 (MicroSoft もタスク
Today, I ran some tests to help me understand the scope in which an eval runs. Turns out, like so many things in the browser world, it's very unpredictable and exhibit different behaviors in different browsers. Let's start with the following snippet of code. I've added comments to demarcate areas in the code, which I will be changing with each iteration. var foo = 123; var bar = { changeFoo: funct
u2viewをそれなりにキー操作できるようにしてみた。 気づいたことをメモ。 ■ Opera9におけるoffsetTop スクロールバーつきだと、「画面上で見えている上端」からの距離になってしまう。 IE6/Firefox2では、スクロールバーの有無に関係なく、本来の上端からの距離になっている。 バグだろうか。offsetLeftでも同じことが起こってそうな予感。 var elem = document.getElementById("foo"); if (window.opera) oTop = elem.offsetTop + elem.scrollTop; // Opera else oTop = elem.offsetTop; // その他 ■ tabindex属性について 1,2,3,...,0(指定なし)の順で移動する。重複している場合は表示順でフォーカスが当たる。 0を指定し
(function(){ var namespace={a:'hogehoge'}; with(namespace){ alert(a); } })(); 上記のコードのようにwith文の中で、どのスコープでも未定義の変数aを使おうとすると、 with文の括弧の中に入ってるオブジェクトのaプロパティを代わりに使ってくれます。 これはもちろんIE・Firefox・Opera共通。 (function(){ var namespace={a:'hogehoge'}; with(namespace){ function fuga(){ alert(a); } } fuga(); })(); 今度はwith文の中で宣言した関数の中で同じく変数aを使おうとした場合です。 Firefoxだとhogehogeとalertが出るけど、 IE・Operaだとaは未定義だと怒られてしまいます。 (functi
Googleがオープンソースのウェブブラウザ「Chrome」をリリースした理由の1つとして、同社は「処理速度」によって実現される、より高速なブラウジングと、いっそうリッチなアプリケーションを追求していることが挙げられる。では、実際Chromeの処理速度は、他のブラウザと比較してどの程度なのか。 Googleは5種類のJavaScriptベンチマークを行った。Chromeはこれらすべてのテストで、他のブラウザを凌ぐ結果を出している(提供: Stephen Shankland/CNET News) Googleのエンジニアで、ChromeのJavaScriptエンジンV8を担当するテクニカルリーダーLars Bak氏は、米国時間9月2日に行われた同ブラウザの発表イベントで、ChromeのJavaScriptの実行速度は、他のブラウザの「何倍も速い」と自負している、と語った。JavaScript
IEとFireFoxでのJavaScript(と言うか主にDOMまわり)の挙動の違いに関するメモ書き 1.ウィンドウ/ドキュメント関連 1.1 ドキュメントの幅,高さの取得 IE6 document.body.scrollWidth document.body.scrollHeight NN6,FireFox document.width document.height FireFox12ではdocument.width,heightはundefinedになる。 https://dev.mozilla.jp/2011/06/firefox6-backward-compatibility/ によると、このプロパティは標準化されなかったので、FireFox6以降で削除された模様。 かわりに、以下のようにしてサイズを取得できる。 parseInt(window.getComputedStyle(
今回から「BK通信」(ビーケーツウシン)と題して、連載することになった高林と申します。以前連載していた「プログラミングの光景」ではデバッグ、コードレビューといった大きなテーマを取り上げましたが、今回の連載では日常的に遭遇するチマチマした「バッドノウハウ」(Bad Knowhow)について書いていきたいと思います。 バッドノウハウとは? バッドノウハウとは、筆者が2003年に作った造語です。元の定義は以下のようなものです。 計算機を使っていると、何でこんなことを覚えないといけないのだろうか、とストレスを感じつつも、それを覚えないとソフトウェアを使いこなすことができないためにしぶしぶ覚えなければならない、といった類いのノウハウは多い。そうした雑多なノウハウのことを、本来は知りたくもないノウハウという意味で、私はバッドノウハウと呼んでいる。 一方、「はてなキーワード」にある定義は簡潔ですっ
開発には firefox3 を愛用していますが、通常のブラウジング用には Sleipnir を愛用しています。あまりに使い慣れてしまったので、他のブラウザへの移行は何度か試したものの Sleipinr に結局落ち着いてしまいます。 ただ、以前も ecl.js (Escape Codec Library) と Sleipnir の相性が悪い件について なんて記事を書いたとおり、Sleipinr で描画エンジンにデフォルトの trident(ieのエンジン) を選択しているとどうにも動作がもっさりする・・・っていうか何十秒もフリーズしたかのように応答なしなる現象が頻発します。そのまま永久に応答なしになったり、突然ブラウザが落ちることもあるので、正直むかつきます。かといって、描画エンジンを Gecko にすると、描画が firefox になっちゃうので、これまた違います。 会社の XP マシンで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く