Background services (Discord, etc) use a negligible amount of processor power. It should be like sub-5% on a modern processor, with the processor clocked down to its lowest frequency. With the processor at turbo, you should be pulling 1-3% easily, even actively using multiple tasks.
These days even Chrome is very aggressive about throttling background tabs, much to the consternation of some webdevs here.
Assuming you are using a reasonable browser with a reasonable set of websites open, a browser should not really burn unbounded CPU in the background. Tabs that do are generally throttled, allowing the scheduler to burst their work and then have the processor go back to sleep.
Could the CPU load be reduced? If I am only on the page, not even playing any music yet (probably because something is blocked), I get 1 core up at 100% CPU load. This can't all be for an animated background image, can it?
I don't really get what he's saying.
Most of the time you will have one active tab, which is consuming a lot of CPU, and all the other tabs in the background will do nothing. Dividing those background tabs onto multiple cores won't bring any significant performance enhancement.
Discord uses 0% CPU (4770k) and 85mb ram on my pc currently, while being in an active call. What would it take for it to no longer be "too bloated" to have idling in the background?
That's wierd - I show a cpu usage of about 48-52% on one of my four threads (2 cores) when I have the tab open, and under 5% on all with the tab closed.
This is on Firefox, Linux.
A side note: I started involuntarily humming the star wars theme to myself as the text started to scroll... I dare say: George Lucas has hacked my brain!
Even in Opera it is less about throttling cpu usage, and more about coalescing wakeups/timer interrupts.
There should never be a situation where background tab cant even get a 1 second timer running reliably, unless its trying to compute pi at the same time.
I've noticed that a lot of sites will end up using 100% CPU usage on their Chrome tab. I haven't investigated, but I do wonder what sort of faulty design leads to this. You occasionally hear talk of sites using your CPU to mine cryptocurrency, but I'm more inclined to suspect lousy programming.
I sometimes wish I had an easy way in Chrome to restrict a tab to, say, 5% CPU, for the cases where the CPU usage is clearly not adding any value. Just so I can get through an article without the fan ramping up.
That would get annoying soon. You won't want your browser to ask for that permission or throttle page layout to use 1% of a single core during page loads or the moment that browser-based shooting game gets lively and requires fast reactions, for example.
I think it would be better to give each tab a power budget that, initially, allows it to run for S seconds at full power, and that give it new budget at a rate of x < 100% of max power every second.
However, I fear that still won't be enough. The list of heuristics and exceptions could get so long that the resulting benaviour becomes difficult to explain.
The CPU usage is around 30% when idle (not handling any HTTP requests) under Windows, so you won't want to keep this app running in background. Otherwise, it's a nice try.
I ran a quick `while true {}` in the background. It used 7B cycles per second (twice the clock speed for some reason?), while Discord uses about 700M. Discord does drop lower if I minimize the window. But still, thousands of context switches per second, while completely logged out. I have no idea what it could be doing.
You're right that I'm probably not benchmarking rigorously enough. But people don't care about any of this stuff. They care about "my FPS gets lower when Discord is open, pls fix". And they don't want to micromanage CPU usage either. Make sure you minimize Discord after starting the call, make sure you close that gmail tab during the game then open it back up when you're done so you don't miss notifications? No thanks. I'd rather just pay for a few more cores.
I guess what triggered me is you saying you cringe at the end users. They don't deserve that. They just want the stuff they buy to work reliably. And if they need a bunch of extra headroom for that to happen, well, that's just the sorry state of the industry. If you must cringe at someone, direct your cringe at developers.
That would be pretty disappointing if they can't handle normal processes too. It's easy to end up with a bunch of processes that are using small amounts of CPU but aren't dedicated background tasks.
Even just looking at a browser, I might have half a dozen generic tab processes open, each using a small amount of CPU. But then I navigate one to a game, and I want that particular tab to get near-exclusive access to the big core while the others use only the little cores.
I'm on linux with a powerful GPU, if that matters.
I noticed that I spend quite some time every day finding and killing tabs that hit the CPU. It's becoming a distraction to my actual productive work: I'm dual tasking. The fans tell me when there's one tab stuck. It's very often the case. Why is the web so complex that so many sites need so much CPU/GPU power? What can you do about it, other than navigating with JS off?
This is a pretty smart strategy. I'd say the majority of the time when something is slow on my machine, it's because there's a resource intensive background process (that I don't really need to complete quickly) eating up all my system resources.
It seems like the same strategy would also make sense on Intel processors, although it probably requires at least 4 cores to make sense?
They most certainly could be related. If you had a few background apps doing something, such as playing music while browsing the web, that would take more clock cycles. Even something like a native twitter app running in the background could be pinging twitter several times a minute, obviously requiring power to do so.
These days even Chrome is very aggressive about throttling background tabs, much to the consternation of some webdevs here.
https://arstechnica.com/information-technology/2017/03/chrom...
reply