4 ms·
Few factors influence this. One is increased screen resolutions. 640x480 display requires about 1.2MB of memory to hold all pixels. a 3840 x 2160 display requ
by mrcode007 3y ago
Few factors influence this. One is increased screen resolutions.
640x480 display requires about 1.2MB of memory to hold all pixels.
a 3840 x 2160 display requires 33MB of pixel data. That’s a ~28x increase. This also means that app assets like icons have increased in size and we use more of them because of larger screens we can fit more of them on the screen.
Next the storage size increased. Therefore we tend to keep data for longer even if it’s unused. More files on storage increases file system and SSD fragmentation, seek times, etc. and a lot of file systems don’t scale very well. Try creating a directory with million files or removing node.js directory with say 100,000 packages installed.
The internet connection speeds increased, so we keep more memory reserved for network buffers so the network stack can service full bandwidth if needed, and because of higher bandwidth we start serving more data in unoptimized formats like JSON because bandwidth is perceived as cheap.
Next up is bigger memory which allows a lot of slack when implementing non-performance critical pieces of code or applications.
When looked at in isolation, those things tend to often not be a big deal but when we put pieces together we get bloat. This gets compounded when applications start fighting for resources on the same machine and you get unanticipated interactions.
- sombragris 3y agoRE: your point about resolutions, you are correct. And also one should add to this: higher color density. We had 16 or 256 colors. Now we have 24 or 32-bit colors which triples or quadruples the amount of memory required to specify any pixel color.
- fuzzzerd 3y ago> removing node.js directory with say 100,000 packages installed. Pain. Just pain, on any system.
- Espressosaurus 3y agoThis is quintupled by so many of the applications treating memory and CPU utilization as if it was free. Electron is an outstanding example of this: let's just ship an interpreter and use javascript for "native" applications. So of course performance frequently sucks. But it's cheap to implement, so there we go. When everything is a webpage, everything incurs the overhead associated with it. Steam takes up ~250 megs. Its webhelper is chewing ~2.5 gigs right now by contrast for me. The bloat is real. I still program against targets with < 1 meg of RAM, but that's fairly uncommon these days professionally.
- __MatrixMan__ 3y ago> This gets compounded when applications start fighting for resources on the same machine and you get unanticipated interactions. One strategy for dealing with this is to use something like k8s to run the various components in different pods. That way you can size each pod such that there are always enough resources set aside for that component, and if it starts getting too big for its britches, you know about it before the whole thing comes crashing down (because they're the britches for just that component). Seems innocent enough, but bearing in mind that internet traffic is bursty, you end up with a situation where your pods are 90% empty 90% of the time because they're all sized for the worst case scenario. The compute you're paying for goes unused most of the time but AWS will still be billing you for 100% it. It's a sort of cancer of the request/response world that we live in. I think we need to go back to the 90's and make a different choice about the web. pub/sub maybe. The cases where we can't tolerate a few minutes of latency are quite small--provided that the data appears out-of-date during that time instead of the app being unusable, which is how we're handling it now.
- mrcode007 3y agoIt’s infeasible on the desktop because for each application you now have a management memory overhead where the container subsystem in the operating system eats up memory for book keeping data structures. Now imagine 1000 apps running and having memory eaten up by running 1000 containers on your desktop.
- __MatrixMan__ 3y agoI don't disagree, but I think that container overhead is the smaller part of the problem. It was recently recommended to me that we should just allocate double the max we've ever seen it consume--switch from 99% unutilized to 99.9% unutilized. Better to be conservative than to get paged in the middle of the night.
- realo 3y agoTrusting 100,000 packages ? Shudders.