Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome 55 uses 30% less memory than 54

prerender.cloud

Post reply on HN
Print view View original

231–236 of 236 posts

Re: Chrome 55 uses 30% less memory than 54

#231

Post by csreis »

sunnyps wrote: post #193
wamatt wrote: post #136

Earlier quoted context omitted.

For me the situation is perhaps not quite as clear cut. On the one hand I'm seeing nice improvements in the large memory hogging tabs. For example a typical reddit thread was reduced from 399 MB down to 295 MB. On the other hand, it appears all extensions now have a >50MB memory usage floor. For example, the Authy extension was using 5MB under Chrome 54. It's now using 55MB on Chrome 55. Similarly the simple archive.…

This might be a side-effect of --isolate-extensions (out of process iframes for extensions) being turned on in M55. https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...

Actually, we decided to delay --isolate-extensions to M56 to get a few more features working for out-of-process iframes first. It's still on for 50% of beta users, but no Chrome Stable users yet. I'll send a clarification to that earlier PSA, but that means that it wouldn't explain an increase in extension memory usage on Chrome Stable.

Re: Chrome 55 uses 30% less memory than 54

#232

Post by brucedawson »

happycodework wrote: post #167
ksec wrote: post #155

Earlier quoted context omitted.

Exactly this. Even though it is not quite 1MB, but more like 5-10MB including all the images. But requiring 250MB of memory, AND some doesn't even load 60fps smooth on latest machines. At times i wonder if there is something fundamentally wrong with the Web Stack.

Fun fact, even though it's downloaded as compressed format, the windows drawing api bitblt requires bmp format, so it's probably saved in memory as bmp. A 1024x768x24bpp bmp is multiple megabytes, even though the jpeg is 100kb. (I think..)

Not just the Windows drawing API, but essentially any drawing API requires that images be decompressed. Some sprite sheets are particularly egregious. I've seen sprite sheets with dozens of 32x32 sprites stacked above each other, and a single wide (let's say 1024x32) sprite at the bottom. This can give you a sprite sheet which is 1024x2048, decompressing to 8 MB, with literally 97% of the data being blank pixels. Fixing this on the browser side is very hard - it's a content problem.

The solution is to lay out sprite sheets to minimize blank space. Rearranging the sprites can easily get the number of blank pixels down to ~5-10%, thus saving ~7 MB, in essentially all browsers.

Re: Chrome 55 uses 30% less memory than 54

#233

Post by Cyph0n »

majewsky wrote: post #228
Cyph0n wrote: post #50

Earlier quoted context omitted.

Awesome, thanks! It's hard being a metric user in the US :P

It seems to do region detection, though. `curl wttr.in/dresden` gives me celsius scale and km/h wind speeds.

Yes, but I'm located in the US, so I get Fahrenheit.

Re: Chrome 55 uses 30% less memory than 54

#234

Post by Fiahil »

vikrantvm wrote: post #97
sillysaurus3 wrote: post #23

Earlier quoted context omitted.

You can run `curl wttr.in` to get your local weather and 3-day forecast. Or just go to http://wttr.in/

This is great. Hope the dev fixes location detection! Weather from the terminal, woot

As mentioned above, you can explicitly specify cities and locations in multiple ways. Chances are, it uses the GMap api (or similar), so you can input pretty much anything resembling a location description. Not sure there is something to fix :)

Re: Chrome 55 uses 30% less memory than 54

#235

Post by robotresearcher »

mortehu wrote: post #215
robotresearcher wrote: post #80

Earlier quoted context omitted.

> processes are allocated their own and thus consume more memory. Copy-on-write means this needn't be a large overhead. Only pages that change after forking are duplicated.

But the OS is committing to supplying memory for any writable pages you duplicated, because after all you might write to them. The OS doesn't know which pages you won't duplicate. Unless you set your vm.overcommit_memory sysctl variable to 1 (= never refuse malloc), duplicated writable pages are going to subtract from available memory, even if all copies are currently the same.

Sure. So your memory usage is reported as high but might not be actually high. Some sophistication is needed to interpret resource counts.

Re: Chrome 55 uses 30% less memory than 54

#236

Post by strcat »

fulafel wrote: post #175
jcoffland wrote: post #58

Earlier quoted context omitted.

This is mainly because Chrome allocates a process for each page whereas FF only allocates a thread. The important factor being that threads share an address space where processes are allocated their own and thus consume more memory. Separate processes are arguably more secure and of one process crashes it does not take down the whole browser but all this comes at a cost. This cost is very apparent with many tabs open…

The primary security gain of sandboxing is about making it harder for web content to hijack your computer by exploiting security bugs. Many common types of bugs can be exploited to get remote code execution in browsers because of unsafe programming languages used (C/C++). Both Chrome and Firefox have multi-process sandboxes now, Firefox is a little behind and plans to enable multiple content processes next year. Whil…

They're shared among site instances, not the same domain. It has to do with web standard semantics. Google has been working on https://www.chromium.org/developers/design-documents/site-is... for quite some time which will probably ship in 2017. That's the next step beyond the --process-per-site-instance after --isolate-extensions.

Firefox is more than just a little bit behind when it comes to sandboxing though... there's a LOT more to sandboxing than splitting up processes. That doesn't result in any meaningful isolation without a lot of further work, and improving sandboxing is a major undertaking that Chrome has been working on for years.

Post reply on HN