Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

101–110 of 403 posts

Re: Chrome will aggressively throttle background tabs

#101
post #6

Archived copy that doesn't require JS: https://archive.fo/3ph1z

Excellent work! Kind of funny the article mentions > This will break the web. But apparently blogger requires javascript just to render static content.

Oh, it's awful, I agree. This is the nicest layout but the JS is terrible.

I've reverted to a plain-HTML layout.

Re: Chrome will aggressively throttle background tabs

#102
post #80

How about displaying more info about the "weight" of a page, when it comes to downloaded assets, cookies / local storage, RAM and CPU usage? I know there are ass backwards and fugly ways to see all of that, but why can't I see a list of all open tabs, with columns of such info which I get to define and sort as I please? Why not have the option to that info pop up when hovering over a tab, and to show notification ico…

It's not everything you asked for, but as it stands Chrome does have a task manager (Shift + Esc) that shows CPU usage, Memory, and also how the tabs are grouped process-wise.

I know, but you can use Chrome for a million years, and have resource hogging tabs crash your computer, without ever knowing about that. Even ("X seems to be slowing down your computer, press shift+ESC for a detailed breakdown") would help. The point is for abusive sites to stick out and have that imaginary free market, with the rational consumers and their informed decisions, do the rest.

Re: Chrome will aggressively throttle background tabs

#103
This is probably a good thing in the long run. Timer-based callbacks can generally be replaced by events, which only trigger when there is actually work to be done. Many JS timers I've seen are needlessly busy-polling.

Whether this implementation affects just timer callbacks or all background processing (eg websocket data events) is a bit ambiguous - this blog post seems to suggest major apps like Slack and Discord will break, but surely they are using websockets and not continuously polling for new data.

Re: Chrome will aggressively throttle background tabs

#104
post #40

So you get to use 1% CPU, effectively. The timer test seems strange, why was your "simple setInterval" using so much more than 1% CPU?

No, you don't get to use 1% CPU. That would still work. The problem is that you get to use 100% of CPU but only 1% of the time.

A timer task is only allowed to run when the budget is non-negative.

After a timer has executed, its run time is subtracted from the budget.

The budget regenerates with time (at rate of 0.01 seconds per second).

I think that would imply that if in any given second, your timer code runs for So for things like sending out heartbeat packets to keep connections alive, I'm assuming that doesn't count, because it happens asynchronously (waiting for the response, I mean)? If that's the case, and your 10 milliseconds only applies to running JavaScript on the CPU, then 10 milliseconds seems reasonable to me. It's a background tab, after all, it's disrespectful of your users to abuse their CPU more than that.

Re: Chrome will aggressively throttle background tabs

#105
post #40

Earlier quoted context omitted.

No, you don't get to use 1% CPU. That would still work. The problem is that you get to use 100% of CPU but only 1% of the time.

Explain how that is different?

It's different because it can't just slow down a running task.

Say you use up 150ms of CPU time. Chrome isn't going to let another timer fire for 15s. Then, you're late on a whole bunch of work that needs to get done, so the next timer takes 500ms. Chrome then throttles the next timer by 50s. And so on and so forth...

Re: Chrome will aggressively throttle background tabs

#106
post #5

Can we aggressively throttle memory usage? Why does it require 300-500MB of ram PER TAB?

Does Chrome only use RAM if it thinks it is available? (i.e. if it starts detecting that other process are running and eating up RAM, will it use less?)

It does try to reduce what it can in low memory situations (less "pre" optimizations like prefetching, prerendering, even dns prefetches and stuff, V8 gets more eager to throw out "potentially unneeded" code, tabs get suspended and written to disk, heuristics can get shut off, etc...), but it can't change what the page does.

If a browser tab wants to store 300MB of data in RAM, or wants to throw a shitton of stuff at the DOM, Chrome needs to oblige.

Re: Chrome will aggressively throttle background tabs

#107

Earlier quoted context omitted.

Pinned tabs would be an easy solution for this. "Don't throttle pinned tabs"

A common use-case is tabs that are streaming music. I'm not sure if most users are even aware of pinned tabs.

I was not, what a great feature!

Re: Chrome will aggressively throttle background tabs

#108
post #16

Can't we use serviceWorkers to workaround this? That's what they were created for. I have a webaudio side project that works nicely even on the background using serviceWorkers for timing. I'm hoping it will be the same on 56.

IIRC service workers are shut off after something like 30 seconds of inactivity.

So it may work for some cases, but not for all.

Re: Chrome will aggressively throttle background tabs

#109
post #54

Earlier quoted context omitted.

Sure, shared/unshared semantics are not hard. How do you map that to a generic concept of "usage"? There's no right way to do it. It doesn't really make sense to ask "how much memory is this process using?" Instead, you want to ask questions like "how much memory are all of these processes using?" or "how much memory would be freed if I terminate these processes?" or "how much extra memory will be used if I start ano…

There's no right way to do it. What's hard is understanding which question you want to ask in any given situation. I don't see the issue. You admit that answering all of these questions is easy. The hard part is lawyering which question to ask. This is not a data reporting problem. This is a data interpretation problem. A good reporting tool should not be interpreting (or forcing an opinion) on the end user. You beli…

"This is a data interpretation problem."

That's what I said. "Defining it is what's hard."

You seem to understand what I'm saying, and agree with me, but insist on arguing for some reason I cannot comprehend.

Re: Chrome will aggressively throttle background tabs

#110

It's awesome to see Chrome trying to improve performance for people with many tabs open, which is many of us. I use a LOT of tabs, and the best plugin has been The Great Suspender. Highly recommend it for anyone who wants memory & CPU back and keeps many tabs/windows open at once: https://chrome.google.com/webstore/detail/the-great-suspende...

I meet many tab hoarders (always open a new one, never close any, ending up with hundrets), but just can't wrap my head around it!

I hate having more than 6-7 simultaneously open because it gets increasingly harder to keep an overview of what you're doing. The same applies for IDE tabs or windows. Too much of them and finding the right one becomes increasingly hard, and losing the thread more likely.

Post reply on HN