Firefox memory link info... - Mozilla

This is a discussion on Firefox memory link info... - Mozilla ; Post from a news.grc.com newsgroup: Interesting and potentially useful information/tools/links, if you're having performance issues with Firefox, by a Firefox developer (and Moz employee). Read the web page for the hyperlinks behind a *lot* of the stuff below. http://www.squarefree.com/2006/02/04...leak-progress/ ------------ ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Firefox memory link info...

  1. Firefox memory link info...

    Post from a news.grc.com newsgroup:

    Interesting and potentially useful information/tools/links, if
    you're having performance issues with Firefox, by a Firefox
    developer (and Moz employee). Read the web page for the hyperlinks
    behind a *lot* of the stuff below.

    http://www.squarefree.com/2006/02/04...leak-progress/

    ------------ [quote]
    One of the more common complaints about Firefox 1.5 was that it
    leaked a lot of memory. I don't know how often these leaks were
    severe enough to cause noticeable slowdowns or thrashing, but enough
    Firefox users seem to care about memory leaks that I thought I'd
    post something about what we've done and what we're doing.

    Two memory leak bugs were fixed in Firefox 1.5.0.1, released earlier
    this week:

    316775 - Leak when selecting.
    317478 - Leaks due to global scope polluter being removed from not
    enough (?) prototype chains.

    In addition, the following memory leaks have been fixed on the trunk
    since the branch point for Firefox 1.5:

    241518 - Calling addEventListener with a closure holding a content
    node leaks the document. (Many Greasemonkey scripts use
    addEventListener, and they each live within implied closures.
    Otherwise, this leak pattern isn't too common, mostly because
    Internet Explorer 6 leaks under the same circumstances.)
    321283 - Using Find causes documents to leak.
    315708 - Should release found link and current window object from
    nsTypeAheadFind.cpp.
    315951 - Unknown content type dialog leaks domwindow.
    319123 - Leak with contentsink-parser-dtd cycle involving
    document.write().
    323441 - Memory leak if a site sets location and then
    document.writes (e.g. when visiting www.economist.com).
    323377 - Lots of leaks in nsInternetSearchService.
    323532 - Leak when using history autocomplete.
    315427 - Bad nullcheck in nsXULPrototypeElement::ReleaseSubtree,
    causing the Options window to leak if the remembered panel is the
    cache panel.
    323534 - CreateTreeWalker can cause leaks due to cycles created by
    closures.
    The trunk seems close to not leaking huge object graphs during my
    typical browsing sessions (YMMV). The only big leak I still see all
    the time is a leak at Gmail. The leak might be related to the
    "unused XMLHttpRequest" leak that David Baron is working on, or it
    might not -- when I asked whether Gmail is considering working
    around the "unused XMLHttpRequest" leak bug, a Gmail coder said he
    didn't think Gmail created any XMLHttpRequest objects it didn't use.

    David Baron's leak-gauge has been allowing more people to test for
    large memory leaks with their own browsing habits, extensions, and
    favorite sites. At least 19 people filed 30 memory leak bug reports
    found using leak-gauge, accounting for more than half of the memory
    leak bug reports (and most of the memory leak bug reporters) since
    its introduction. The bug reports look pretty useful, and are
    definitely more useful than general complaints about high memory
    usage after using Firefox for a few hours.

    If you're still suffering a lot from memory leaks in Firefox 1.5.0.1
    and/or want to help find memory leak bugs, head over to The Burning
    Edge and try out a trunk build. If you prefer to stick with stable
    versions of Firefox, don't worry -- many of the fixes that are
    currently only on the trunk will be included in the next scheduled
    update (currently planned to be called Firefox 1.5.0.2 and released
    in March), most of them will be included in Firefox 2, and all of
    them will be included in Firefox 3.

    Leaks in extensions
    Recognizing that memory leaks aren't always due to bugs in Firefox
    itself, Steve England and others have tested popular Firefox
    extensions for memory leaks. They found that Session saver,
    NoScript, IE Tab, and the combination of FlashGot and Filterset.G
    Updater cause leaks.

    Giorgio Maone, the author of NoScript and FlashGot, has already
    fixed the biggest leak in NoScript thanks to Steve's bug report. He
    is now working on threading issues in FlashGot that prevent
    debugging and might be responsible for the leaks. Authors of the
    other extensions haven't been as fast to fix their leaks.

    I also fixed several minor memory leaks in my own extensions
    recently, some found through code inspection and some found using
    leak-gauge. Search Keys 0.7.2 and below kept parts of search result
    pages alive for the lifetime of the window due to an unintentionally
    global variable (a missing "var"). Thumbs 0.6.1 and below kept the
    DOMWindow for the page Thumbs was last used on alive until shutdown.

    Other causes of high memory usage
    Memory leaks aren't the only thing that can cause Firefox to (appear
    to) use a lot of memory. See MozillaZine Fourms: Memory usage FQA
    and MozillaZine KB: Reducing memory usage.
    -------- [end quote]


    --
    Jordan

  2. Re: Firefox memory link info...

    _Jordan_ spoke thusly on 07/02/2006 1:33 AM:
    > Post from a news.grc.com newsgroup:
    >
    > http://www.squarefree.com/2006/02/04...leak-progress/


    http://groups.google.com/group/mozil...dc453726d8ed44
    :-)
    --
    Chris Ilias - Mozilla Champion
    mozilla.test.multimedia moderator
    Mozilla links
    (Please do not email me tech support questions)

  3. Re: Firefox memory link info...

    Chris Ilias wrote:
    > _Jordan_ spoke thusly on 07/02/2006 1:33 AM:
    >> Post from a news.grc.com newsgroup:
    >>
    >> http://www.squarefree.com/2006/02/04...leak-progress/

    >
    > http://groups.google.com/group/mozil...dc453726d8ed44
    > :-)


    Gosh darn! ;-)

    --
    Jordan

  4. Re: Firefox memory link info...

    The calendar extension certainly seems to be a memory leak culprit. I open
    FF to usual yahoo home page 31k in memory and then opened calendar to see
    what would happen. Memory jumped to 35k which is fine but when I closed
    calendar the memory was not released. Every subsequent opening of calendar
    added 3-5k of memory and returned none on closing.

    Is that a problem?

    Bill



    "Jordan" wrote in message
    news:CL-dncVF_-XJonXeRVn-vg@mozilla.org...
    > Post from a news.grc.com newsgroup:
    >
    > Interesting and potentially useful information/tools/links, if
    > you're having performance issues with Firefox, by a Firefox
    > developer (and Moz employee). Read the web page for the hyperlinks
    > behind a *lot* of the stuff below.
    >
    > http://www.squarefree.com/2006/02/04...leak-progress/
    >
    > ------------ [quote]
    > One of the more common complaints about Firefox 1.5 was that it
    > leaked a lot of memory. I don't know how often these leaks were
    > severe enough to cause noticeable slowdowns or thrashing, but enough
    > Firefox users seem to care about memory leaks that I thought I'd
    > post something about what we've done and what we're doing.
    >
    > Two memory leak bugs were fixed in Firefox 1.5.0.1, released earlier
    > this week:
    >
    > 316775 - Leak when selecting.
    > 317478 - Leaks due to global scope polluter being removed from not
    > enough (?) prototype chains.
    >
    > In addition, the following memory leaks have been fixed on the trunk
    > since the branch point for Firefox 1.5:
    >
    > 241518 - Calling addEventListener with a closure holding a content
    > node leaks the document. (Many Greasemonkey scripts use
    > addEventListener, and they each live within implied closures.
    > Otherwise, this leak pattern isn't too common, mostly because
    > Internet Explorer 6 leaks under the same circumstances.)
    > 321283 - Using Find causes documents to leak.
    > 315708 - Should release found link and current window object from
    > nsTypeAheadFind.cpp.
    > 315951 - Unknown content type dialog leaks domwindow.
    > 319123 - Leak with contentsink-parser-dtd cycle involving
    > document.write().
    > 323441 - Memory leak if a site sets location and then
    > document.writes (e.g. when visiting www.economist.com).
    > 323377 - Lots of leaks in nsInternetSearchService.
    > 323532 - Leak when using history autocomplete.
    > 315427 - Bad nullcheck in nsXULPrototypeElement::ReleaseSubtree,
    > causing the Options window to leak if the remembered panel is the
    > cache panel.
    > 323534 - CreateTreeWalker can cause leaks due to cycles created by
    > closures.
    > The trunk seems close to not leaking huge object graphs during my
    > typical browsing sessions (YMMV). The only big leak I still see all
    > the time is a leak at Gmail. The leak might be related to the
    > "unused XMLHttpRequest" leak that David Baron is working on, or it
    > might not -- when I asked whether Gmail is considering working
    > around the "unused XMLHttpRequest" leak bug, a Gmail coder said he
    > didn't think Gmail created any XMLHttpRequest objects it didn't use.
    >
    > David Baron's leak-gauge has been allowing more people to test for
    > large memory leaks with their own browsing habits, extensions, and
    > favorite sites. At least 19 people filed 30 memory leak bug reports
    > found using leak-gauge, accounting for more than half of the memory
    > leak bug reports (and most of the memory leak bug reporters) since
    > its introduction. The bug reports look pretty useful, and are
    > definitely more useful than general complaints about high memory
    > usage after using Firefox for a few hours.
    >
    > If you're still suffering a lot from memory leaks in Firefox 1.5.0.1
    > and/or want to help find memory leak bugs, head over to The Burning
    > Edge and try out a trunk build. If you prefer to stick with stable
    > versions of Firefox, don't worry -- many of the fixes that are
    > currently only on the trunk will be included in the next scheduled
    > update (currently planned to be called Firefox 1.5.0.2 and released
    > in March), most of them will be included in Firefox 2, and all of
    > them will be included in Firefox 3.
    >
    > Leaks in extensions
    > Recognizing that memory leaks aren't always due to bugs in Firefox
    > itself, Steve England and others have tested popular Firefox
    > extensions for memory leaks. They found that Session saver,
    > NoScript, IE Tab, and the combination of FlashGot and Filterset.G
    > Updater cause leaks.
    >
    > Giorgio Maone, the author of NoScript and FlashGot, has already
    > fixed the biggest leak in NoScript thanks to Steve's bug report. He
    > is now working on threading issues in FlashGot that prevent
    > debugging and might be responsible for the leaks. Authors of the
    > other extensions haven't been as fast to fix their leaks.
    >
    > I also fixed several minor memory leaks in my own extensions
    > recently, some found through code inspection and some found using
    > leak-gauge. Search Keys 0.7.2 and below kept parts of search result
    > pages alive for the lifetime of the window due to an unintentionally
    > global variable (a missing "var"). Thumbs 0.6.1 and below kept the
    > DOMWindow for the page Thumbs was last used on alive until shutdown.
    >
    > Other causes of high memory usage
    > Memory leaks aren't the only thing that can cause Firefox to (appear
    > to) use a lot of memory. See MozillaZine Fourms: Memory usage FQA
    > and MozillaZine KB: Reducing memory usage.
    > -------- [end quote]
    >
    >
    > --
    > Jordan




+ Reply to Thread