Not bad 3GB. I don't want to see this code. Bloat strikes again it seems
dom workers linger for some time but eventually go away. If you enabled service workers via pref this still needs fixes.
2.53 memory leaks
> Seems web workers may be the source of the leak,
Not bad 3GB. I don't want to see this code. Bloat strikes again it seems dom workers linger for some time but eventually go away. If you enabled service workers via pref this still needs fixes.
Something wrong there, I'd say. Certainly not in a new, clean Profile, opening to about:blank. Rather possible if you're opening from Session Restore, restoring multiple tabs/windows, loading content from who knows where...
On my end, as RAM usage rises, regardless of x64, UX deteriorates. How much RAM, & where you start experiencing issues may vary, but they'll hit you. In all browsers. (FF Quantum will usually go longer without negatively affecting you, compared to SeaMonkey. So if I'm visiting "trash" sites, I may drop down to FF to do so.) (Ate breakfast the morning, & when I came back, FF had eaten 42 GB of RAM. That was NOT a pleasant experience. Surprised that I [eventually] gained enough control to Quit out cleanly [rather then having to kill it outright] [& it took a LONG time before it finally exited memory & a while after that before my [overall] system started acting fairly normally. [16 GB physical RAM.])
Let me fix that... There are sufficient reports of high memory consumption affecting performance [pick whatever application you want to, & enter, here] to consider this a widespread problem affecting a large number of users. I believe that there is a problem with [pick the application you want to, & enter, here] which needs to be fixed. Yes, memory leaks, yes memory hog... easy to say. Much harder to quantify in a meaningful, repeatable way, that actually points out an actual bug, that can be fixed. So if you open your browser, cleanly, & it's using 2 GB of RAM, yes that is an issue - but that is your issue, not a general application issue affecting >2.
Now we might be kind of getting somewhere. So... if you make a copy of your 2.53 Profile, complete, as is, 2 GB & all, & open that Profile, complete, as is, in an instance of 2.49 (try that in FF Quantum without jumping through hoops  ) [& even that may not be "kosher" - except for testing purposes], are you going to tell me that what opens as 2 GB in 2.53, opens at a rather svelte 300-400 MB in 2.49?(And let me answer that. No, that will not be the case. They will both open using similar amounts of RAM, ~2 GB. Differences, yes, but not 400 in one & 2 GB in the other. And if that were the case, then you can say, ah, something isn't working correctly here. Then, you have to figure out what. Like is it an extension that is the cause [as pointed out earlier] or is there an actual issue in 2.53... or?) Oh, & lets not forget that everything in x64 is bigger compared to the same in x86 (if you were using x86 2.49 vs x64 2.53).
And shouldn't it? Saying it went from 2 GB to 3 GB is a rather meaningless statement. If you opened it, did nothing further (like I went & ate breakfast) & it ate RAM (42 GB in the case of FF for me), then I might be able to shout out - FF is a RAM pig (well, at 42 GB, I'd say yes it is) - but, but was there a fault with FF? Maybe, but I don't know? Or was it some page I happened to have open, or an extension, or some combination that caused this chewing of the fat issue? I've never seen 42 GB - before - anywhere. Surprised FF didn't actually crash. I would have expected a crash in it (or in SeaMonkey - almost assuredly in SeaMonkey - given equal circumstances). So best I can say is, "something happened" (trump is good at saying stuff like that). I can shout "42 GB" all I want, & as impressive as it sounds, it is meaningless. Fire 750, bring back 250.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript
I left the browser idle for an hour, they didn't go away
I didn't, this is on mostly unmodified profile Checked current Firefox on the same site, it doesn't have that worker at all, and no such big memory usage observed... UPD: "I left the browser idle for an hour, they didn't go away" After testing Firefox I've pressed Measure in SM one more time, and that worker finally gone
I wonder if the RAM leaks are exclusive just to the SM 2.53.x releases
I don't seem to have the problem with SM 2.49.x and unofficial SM 2.57a1pre builds from wg9s
So your lone comment in this thread:
viewtopic.php?p=14866582#p14866582 And now we're up to a conspiracy theory of 2.53 being rubbish. That's grand. And the only substantive comment in the entire thread, is what Px wrote. (Granted, you don't know how to read the memory reports. I don't either. Much less if anything there is meaningful. Anyhow, continuing to spout hot air, this post included, is just that.) Fire 750, bring back 250.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball CopyURL+ FetchTextURL FlashGot NoScript 
Yep, internet forums are just a microcosm of real life. Metal Lion latest SeaMonkey & Thunderbird Themes - Sea Monkey and Silver Sea Monkey
"The only thing necessary for the triumph of evil, is for good men to do nothing." - Edmund Burke (attrib.)
Just to add a little investigation:
470,000 meg Firefox portable (32 bit 68.11) 390,000 meg Palemoon Portable (32 bit 28.11) 287,000 meg SeaMonkey Portable (32 bit 2.53.3) Nick -N- Quis custodiet ipsos custodes
SeaMonkey(32bit), Acer Spin, Windows 10 Pro (X64 v1909), WinPatrol, Malwarebytes & PandaDome
/* Cough */
/* Cough */  
Px
So, you use 514.60 megs at https://console.paperspace.com My reading with System Explorer is 352,16 meg (no other tabs or windows open, which is not my normal usage. I average around 5 tabs open and try not to use windows at all) -N- Quis custodiet ipsos custodes
SeaMonkey(32bit), Acer Spin, Windows 10 Pro (X64 v1909), WinPatrol, Malwarebytes & PandaDome
Just noticed:
512.00 MB (02.82%) ── non-heap/elements/wasm Set javascript.options.wasm to false and see how it goes. wasm is bleeding edge work in progress and was/is probably barely usable in 56 to 60 times. 2.49 not affected because it didn't have it. We didn't backport much here yet. FRG
Are these instructions for everyone as a measure to hold down the memory build up? Is it safe for a very basic user to do it? Thanks. . . . . . . . . . . Pete
> Are these instructions for everyone as a measure to hold down the memory build up?
It is very unlikely that this is the cause for all the reported issues. wasm use is not in use widespread and the sites where I tested where either completely broken or it did work for me. > Is it safe for a very basic user to do it? Yes. Noticed that I had set it to false for some time. Wasm is probably something malware authors will like very much now that java in the browser is gone. FRG
Thanks. Okay, it sounds like this approach is a non-starter for us basic users. . . . . . . . . . . Pete
I've recently found that increasing the parameter in about.config:
javascript.options.mem.gc_allocation_threshold_mb from its default 30 MB size to 96 MB or even 128 MB on Windows has decreased SM memory usage drastically. As I have just made this adjustment very recently, I'm still in the process of testing what difference it will make to SM memory and resource leakages over the next while. I have both SM 2.53-64 and 2.49.5-32 running on different Windows versions and on the latter version it has made a huge difference though interestingly more CPU utilization at times can occur on the multi-core processor it is running on. I've made the same adjustments to Firefox-ESR 32 and 64 bit releases of current and older versions and will also observe whether it reduces RAM consumption as shown in Windows task manager.
Unfortunately, didn't help at all, and broke the site actually, reverted it back. With wasm false
Who is onlineUsers browsing this forum: No registered users and 3 guests |
|
