I have provided tons of info several times, see these two treads:
viewtopic.php?f=3&t=20573&hilit=freeze
viewtopic.php?t=20882
Moderator: trava90
I have provided tons of info several times, see these two treads:
I understand that you feel it superfluous, but:
Maybe wait till you can reproduce it on a fully spec'd system and share relevant logs/troubleshooting info/screenshots from there instead of bloviating here. People here aren't telepathic to be able to figure out what's wrong without providing complete and relevant info.
Thanks for the detailed explanation. Is it possible to separate out memory usage or leaks from misbehaving extensions? As I understand, XUL extensions are sort of 'in process' (for want of a better word) with the browser's own core, and were blamed for Mozilla deciding to dump XUL altogether because they couldn't be bothered with having to troubleshoot multiple combinations of extensions with users complaining about high memory usage/low responsiveness.Moonchild wrote: ↑2019-08-27, 10:05As for memory not being immediately freed otherwise, that is very much by design. A lot of the browser and platform uses buffering and caching memory pools for performance reasons. For example, there's a surface cache that will hold up to 1 GB of decoded and rendered image data so they won't have to be redrawn -- that will not be immediately released when closing a tab. There are similar mechanisms for page content as a whole and composited data. All of that is on purpose, and depends on whether there is memory pressure or not when and how it's released. In addition, application memory is not as straightforward when looking at numbers, so you have to keep in mind that a "working set" or "committed" memory number is not necessarily actually allocated or exclusive to the application.
Some extensions misbehave sometimes like any javascript that is executed. Only as good as the code is. But Mozilla is fake news and obviously we have a generally performant XUL based platform with full extensability using the power of XUL. So while that could be a contributing factor.. It wasn't for them. They have shown us that a rich extension system using the technology the applications them selves use is completely antithetical to being able to redefine the browser every 30 seconds so it won't be racist or something.moonbat wrote: ↑2019-08-27, 12:56As I understand, XUL extensions are sort of 'in process' (for want of a better word) with the browser's own core, and were blamed for Mozilla deciding to dump XUL altogether because they couldn't be bothered with having to troubleshoot multiple combinations of extensions with users complaining about high memory usage/low responsiveness.