QUOTE(AhumanRS @ Dec 10 2020, 20:40)
Why does chrome need to take a gigabyte of my RAM?
Memory leaks, maybe.
Basically, a memory leak works like this (although the exact chain of events leading to it may vary; I'm just making up an example of how someone might accidentally let it happen. It's extremely oversimplified):
>Be Chrome
>User wants to open a page
>Hmm, looks like we need to download the pictures that go on the page
>There are ten pictures and each one is (for this example) 2 MiB
>Let's make an array of the images (ok, it might actually be a linked list in real life, but this is an example, so whatever. Arrays are easier to understand)
>Let's call the C/C++ malloc() function, which allocates space in RAM to temporarily hold these images
>image_cache_array[0]=malloc(2097152); /* 2097152 is 2 MiB */
>...
>image_cache_array[9]=malloc(2097152); /* last image has been allocated for */
>fills in allocated memory with the contents of the images. When the tab is closed, `free()` is called on each element of the array in order to return the RAM to the operating system (the browser basically says "I'm done with this now, so here you go, OS.").
Okay, now for the leak
>User opens a new tab and loads page 2 of forum thread
>Chrome tries to save resources by using the stuff in the RAM cache that's the same as it was on the last page (like, say, the banner image or the emotes that some people use, or forum signatures/profile pics). image_cache_array[4] is in use on both tabs now
>But this means that it now has to remember NOT to call free() on certain images from tab 1 until both tabs are closed or the site is navigated away from
>Browser tab 1 crashes for whatever reason (not memory leak related), or some other problem occurs. Maybe the user tried to reload an image on the page.
>In order to not crash tab 2, tabs that crash have to have special handling to clean up the left-over mess while not treading on other tabs' resources
>Cleanup function fucks up and doesn't free() a resource that was only on tab 1Congrats, you now have a memory leak. Nothing in the program knows where the image data was allocated in RAM anymore, but the RAM hasn't been returned to the OS either. So until the program is closed entirely, it will just float around in memory doing nothing but taking up space.
Garbage collectors can solve this problem, and indeed that's basically what my hypothetical "cleanup function" is, but it can be hard to cover all edge cases in complex programs like this. And C/C++ themselves don't usually use automagic garbage collection, meaning you have to write your own garbage collector.
The other reason of course is that malloc()'ing stuff takes time, and it could be that chrome/chromium prefers to reuse existing malloc'd space instead of allocating additional storage. I don't know about this for sure though.
This is all extremely oversimplified of course, and I doubt that Chromium actually does it exactly like this because it's not really the best solution in large projects. It's just how they generally work in software as a whole.
QUOTE(EsotericSatire @ Dec 26 2020, 02:00)
the animated .png lol
Which animated png?
Also, Chrom(e/ium) finally started supporting APNG a couple years ago. The last major holdout was MS Edge/IE, and Edge supports APNG now that it just uses Blink (is another Chrome-clone).
I can't say I even prefer Mozilla anymore, since recently Mozilla started using node.js in its build system, and there is no working current version of node.js for 32-bit big-endian PowerPC, which means it's hard (maybe even impossible) to build a modern version of Firefox for it. Last time I cross-compiled it, even without node or Rust shit it was hard enough.
It's also kind of funny that Moz is using Node instead of its own Javascript engine to build its javascript engine.
My Powerbook G4 (running Linux) is still running the Seamonkey build I made for it in 2018 (2.49.3; based on FF 52 ESR). Still adequate for most tasks for now, and my build actually has several performance fixes for PPC, but not looking forward to trying to update it anytime soon.
Still, it's more portable than Chromium. IBM did make a POWER architecture port of Blink (actually the main part that needed porting was V8, the Javascript engine), but last I checked it only built and ran properly on the more recent 64-bit POWER architecture versions (not on a G4 or "G5/970"). At the very least, it may be possible to convince it to use the native NodeJS on an x86 or amd64 machine and a cross-toolchain. Though I have no idea how to cross-compile Rust code.
This post has been edited by dragontamer8740: Dec 26 2020, 18:06
Chrome or Firefox
Dec 11 2020, 02:04
