The Great Suspender
A similar product that stops unused tabs after a short period so that they don't consume resources. Works for me.
Or via the Chrome Extensions page.
The US government may have trouble regulating Google – but one of its developers has come up with a way to rein in the Chocolate Factory's resource-hungry browser. David Flater, a computer scientist at Uncle Sam's National Institute for Standards and Technology (NIST), has created a Chrome extension for killing excessive …
I think it's a combination of DLLs that don't (more static than dynamic), shared libraries that don't and a long standing habit of ignoring efficient coding on the assumption that the user will buy faster hardware to run it on anyway.
From a usability perspective, a lot of time is wasted on irrelevant crap - that you have to wait for a wordprocessor is IMHO a hardcore criminal waste of computer resources.
This leads me to irritation 2: I cannot believe we need such a massive amount of computer power just to show a graphical environment, especially since most of the imaging is now handed off to a graphics card. We used to do that with a bloody Pentium, even WITh the floating point bug (sorry, jut wanted to rub that in again :) ).
Try this at some point.
Install a copy of an old MS OS. Win7, Vista, XP, 2k, 98, whatever. Watch how quickly it does everything.
Now download and apply all of the patches. Watch the performance difference. A sceptic might think that Microsoft was deliberately screwing their old OS's to make the newer ones look better. Of course, one should never assume malice when incompetence can be an adequate explanation.
As I’ve posted before, Win2k server, yep took some gig on disk but surgically removing a lot of Microsoft services services and features unneeded for WAMP, I got all services up and running to the GUI with less than 32 meg of ram.
I still have a ‘when I have time’ project to make a win10 VM and start doing the same to that - restoring a vm is far easier than the install and update cycle that lasts forever...
I'm not sure that's an operating-system-specific comment.
I have a project that's about ~60,000 lines in total. With the latest Clang, all optimisations turned up to the appropriate maximum, the binary it produces is 21,595,120 bytes in size.
I comment to a ridiculous volume, and write for legibility, avoiding code-golf-esque monstrosities, so suffice to say that the implied 360 bytes per line is somewhat of a surprise.
It's C++ but I'll use a template only when there's actually some generic behaviour to describe. At one of my previous workplaces I knew somebody who seemed to believe in templates to allow completely different code paths for almost all runtime selection — anything you'd normally pass to a constructor by value he'd try to work into the template directly. "For performance", obviously.
One of his ~30,000 line projects could no longer be built for 32-bit targets because the binary it produced was larger than 4gb.
I remember years ago talking (e-mail) with one of the KDE devs (Kde3?). Parts of the system were gobbling up huge amounts of RAM (for the time)
He mentioned that one of the problems is C++ and the way it has to build the VirtualTable crap for each and every class function/method pointer; This leads to the VTable blowing out to HUGE dimensions.
So for even relatively simple libraries you end up in this O^2 situation as each library loads for each thread. It's not that the library has to load twice or more(It's a shared page); it's that it has to build a unique set of VTables each time for each thread. This means the the VTables ended up many time the size of the code itself
1st time I've seen CPU usage
Really? Can't you do a conky-like thing on a Chromebook? Just asking, have no personal experience with Chromebooks. Too cloudy for my workflow...
As for the Reaper... Isn't uMatrix available for Chrome? I mean, if you want a good method to reduce browser CPU load, that excellent piece of code is one of the ways to do it effectively.
It took a while for the wheel to go full circle but finally browser developers caught the cluetrain and realised that having each tab or window simply as a seperate thread is bad news when it crashes and takes down the entire browser, so went back to using multiple processes as was done back in the day. How that works in Windows with its crippled process model and no support for fork() or similar niceties is anyones guess but at least its happening now which means you don't even need an extension - just use ps or top to monitor browser processes and kill them individually if theres a problem.
How that works in Windows with its crippled process model and no support for fork() or similar niceties
I'm not a particular fan of the Windows process model (though thread security tokens, for example, were arguably a good idea), and Windows processes are very heavy. As someone who routinely develops on both Windows and UNIXy platforms (and has worked on a variety of others), I often miss the relative elegance and performance of UNIX when I work with Windows.1
However, since XP, Windows has made it relatively straightforward to schedule work in a pool of preexisting child processes using CreateRemoteThread(Ex), which is quite fast. So the worker processes can be started ahead of time (with the pool expanding and contracting as needed), amortizing the process startup cost.
There's an obvious security concern with CreateRemoteThread, compounded by Microsoft's braindead treatment of process-handle privileges - to watch for the termination of another process, for example, you need the same privilege as you'd need to invoke CreateRemoteThread on it, so there's no safe way to permit only the monitoring of another process. And its use obviously requires care. But as a fast IPC mechanism for related processes it can work pretty well.
1Of course, in the days before demand paging and COW, UNIX fork() wasn't exactly ideal either.
Right, unless the browser takes steps to limit the resources consumed by the scripting engine. And I don't know offhand of any that do, because Users Would Complain.
The ECMAScript standard would have done well to adopt some sort of resource limitation mechanism, possibly along the lines of POSIX setrusage or Chez Scheme's engines. Browsers could suspend scripts when they hit limits, then prompt users to grant more resources; with a whitelisting mechanism that could work fairly well.
Of course many technical users run something like NoScript, but even that is a pretty coarse mechanism. (I'm always annoyed that NoScript can't temporarily whitelist scripts just for a tab or site, so when I run into some idiotic site that requires, say, Google Tag Services to function, and I have a compelling reason to use it anyway, I could just temporarily whitelist it for that tab only. Instead I have to fire up another browser instance to prevent every damn tab in the world from loading it.)
In my experience, it's a Chromium thing. I have been using Opera before and after the switch to the Chromium engine and have noticed the new Chromium-based Opera was just as resource hungry as Chrome was before I stopped using it. Even The Great Suspender wasn't helping all that much with Chrome's appetite for resources; haven't tried it with New Opera.
FF is my non-Chrome browser of choice, but it has some nasty habits. I like to have 6 or 7 tabs open at a time, and just leave the browser there. Even with adblock/noscript, after a few hours some tabs (Facebook, BBC) just start to use a little more CPU - and a little more - and a little more,. until it's actually quicker to power cycle and restart (3 minutes) than wait for whatever it is to stop (over 10 minutes once ... which I know because the clock freezes).
This is under Linux Mint, too ....
I would make a shout-out for pi-hole at this point. Latest versions of FF and Chrome on Mint - since I spooled up pi-hole at the weekend it's been blocking 60% of requests (and this is with umatrix running) and the footprints in both instances have not increased. At least not appreciably - whereas in 72 hours I would expect to see it. Might be worth a look.
Funny enough I'd left Edge open overnight with 3 basic office365 tabs open (doing nothing). In the morning the 8GB PC had no memory left and edge was showing 3.5GB used.
Very difficult to shut it down. Chrome was also running with about 40 tabs open but less than 1GB of memory used.
Even with adblock/noscript, after a few hours some tabs (Facebook, BBC) just start to use a little more
You might want to close that and other resource heavy websites after you're done.
None resource heavy website (ex:El Reg) can be kept open for as long as you want without using up all your resources.
This is under Linux Mint, too ....
You do know that Linux has POSIX limits (setrusage / ulimit), right?
If you start the initial Firefox process with reduced CPU limits, the kernel will kill it or any of its children for you when they hit the limit. No need to reboot the whole machine.
Worked in the Netherlands on a VAX environment where someone wrote a program called 'Magere Hein' (local nickname for the Grim Reaper) which killed of processes that seemed to nothing for long periods of time. Exceptions could be made, but you had to justify them
It forced you to save your stuff.
I've successfully installed and am running Reaper in Chrome, Chromium and Brave. I'm won't be testing other Chromium variants (such as Opera). But I expect it is safe to assume Reaper installs and runs fine with them as well. Go for it!
NOTE: With Brave you have to change the command "chrome://***" to "brave://***" when setting up and installing Reaper. The regular "chrome://" command works fine with both Chrome and Chromium.
Thank you NIST! If only the rest of my US government paid heed to your computer security recommendations!
... give all the developers old, slow PC's for writing software on. The trouble with developers is that they all seem to run computers that are state-of-the-art and screaming fast, nothing like the laptops a lot of their customers are running. In the real world, Windows PC's are 3 years old, underpowered, patched and patched and overpatched, running anti-virus live scanning that takes up to 85% CPU under 'normal' circumstances, and since we have to get real work done, on top of all that we have to run a word processor, a spreadsheet, email software, and on and on. It's no wonder that code that looks so nice on a developer's shiny new workstation, running all by itself, ends up dogging my system. I spend quite a bit of time just watching stuff crawl along in Task Manager, as the CPU stays pegged at 99% utilization. All 4 cores, at that.
Did you know, that's pretty much what the makers of the game MDK did back in the day. They designed the game then tested it on old hardware, and tweaked it over and over until it ran well on that kit.
These days, if the software runs slow,they expect you to fork out for better hardware, rather than clear out the unused crap.
It's even easier than that. You give them old, slow PCs for *testing* software on. They can use the shiny new box for writing it. I don't mind that. What matters is that the separate "test PC" that they deploy to for, er, "testing" should be similar to the target customers' boxes.
(For all the non-developers out there I should point out that any developer who doesn't have a completely separate test system that they can strip down, rebuild and general hack about with to their heart's content to explore various test scenarios ... basically isn't a real developer. They're a script kiddie being indulged by HR with a fancy job title.)
I also like Indie games devs for games that take 5 years to release.
The "Easy" mode is impossible to beat. Well, what do you expect of balance, when someone has had 5 years to train themselves and only the most hardcore Alpha/Beta testers to give them advice on balance?
Seen it happen so many times.
give all the developers old, slow PC's for writing software on
We have a similar technique: Give the developers new laptops, but put Windows 10, Visual Studio, and McAfee on them. Slows them right the hell down.
My 1-year-old Dell Latitude something-or-other is noticeably slower at running the same builds as my 5-year-old Latitude. The 1-year-old has a faster CPU and an SSD, but the older one is running Win7 and Symantec (as useless as McAfee, but does nothing useful faster). The difference is significant - typically around 15%, which means at least a few minutes for the build in question.
The new one does run Linux in a VM somewhat more sprightly than the old one does, so it's not a hardware problem.
Biting the hand that feeds IT © 1998–2019