Element.extendの動向。

最近prototype.jsではSelectorとDOMがよく動きます。 仕事でも使っているし、重要な部分なのでここのところウォッチしています。

最近、実は書こうと思ってたElement.extendの問題が解決されました。 問題:Incredible memory leak in IE

これは見る人が見ればパッと見で「これはヤバいんじゃね?」と思ったんじゃないでしょうか。 わからなかった人は上記のURLにも載っている http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ietechcol/dnwebgen/ie_leak_patterns.asp を見ておくと今後悩むことが減るかもしれません。

リンク先をみたらなにが問題かわかるのであえては書きません。

もう一個、興味深いのは Element.extend cripples $() performance での議論です。 前に書いた記事 と似た主張や議論がなされています。うちの会社にも英語苦手な人がいるので簡単に要旨を。

  • Element.extendはパフォーマンスに問題がある。前のままにしてほしい。

    • http://dev.rubyonrails.org/changeset/4094 でだいぶマシになっているよ?
    • 解説:以前はそれぞれのElementについてElement.Methodsのメソッドにelementをbindしてコピーしていた。つまりElementの数に比例してメモリを使用する。しかし4094でキャッシュを導入したので一定数のメソッドしか生成しない。
    • とりあえずElement.extendのパフォーマンスをあげることにフォーカスしよう。
    • Element.extend = Prototype.Kってかけばとりあえず大丈夫じゃね?

      • でもscriptaculousが完全にextendされてる前提でコードかいてるから動かなくなるじゃん。
      • 解説:scriptaculousは3月28日にprototype.js 1.5_pre1をバンドルしてバージョン1.6をリリースした。このバージョンではelement.setStyle({top: “})とかelement.show();みたいにガンガンElement.extendを活用している。まぁとりあえずElement.extendが必要ないときはPrototype.Kにしとけばいい。
    • FirefoxやSafariは高速化できる(前のエントリーとほぼ同じ)。しかしprototype.jsに組み込むとscriptaculousのElement.Methods拡張が反映されない。

というわけでElement.extendはこれでちょっと落ち着いた感じ。個人的にはElement.extend無効化して使っていきたいなーって思ってたりしてたんですけどscriptaculousがやっぱりガンガン使ってきたので、まぁ様子見てみます。

comments powered by Disqus