Most of UNIX's utilities were written with high regard for their memory use. When GNU decided to clone them all, they actually outlined that their developers were forbidden to even review UNIX sourcecode. Convention stated that they all try to write the programs with speed in mind, and now we have these discussions.
I don't think you should optimize for space or speed at each others expense without figuring out if the trade-off is worth it.
Space and speed will always be conflicting goals during optimizations (unless you're very lucky), and for practical use the sweet spot is usually somewhere in between the two extremes.
To blindly optimize for speed will result in very wasteful behaviour when it comes to memory usage, to blindly optimize for space will result in terrible performance.
Smart software realizes when the space is available and free for the taking and will use it to find an increase in speed, it will also realize when space is at a premium and economize on it's usage.
On another note, accessing all that memory costs cycles and is almost certainly going to trash your cache, chances are that if you manage to reduce your memory footprint eventually you'll find that instead of losing speed you're gaining speed.
Open Office started up with a blank word processor document uses 83 Megs of RAM, something tells me that could be a whole lot less without sacrificing functionality or speed.
I agree completely that one should not optimize for one area without taking in account the penalties incurred on the other areas. I hope I didn't give that impression.
One of the more major reasons of GNU developing the habit of writing utilities that were significantly different in their implementation was to make sure no UNIX/BSD code could leak in, since at the time the project was underway, BSD was stuck in that whole USL vs BSDi suit, and BSD's code was tentatively deemed 'non-free'.
One also needs to account for the time period these utilities were written, and for what computer system they were originally written for. Both memory and speed were expensive. Writing these utilities probably required much more thought to the smaller details than one would think about today when writing say a word processor, even though one could benefit by doing so.
Having lots of memory can serve as a poor-man's SSD. At least on a Linux system files are read from the disk and left in memory until that memory is needed for something else. This can increase responsiveness by reducing the need to go to disk for frequently used filesystem data.
The stable version of Chrome leaks memory like crazy on Linux. I was frequently using over 1gb according to about:memory and have seen it use up to 3gb. 6.0.495.0 dev seems to be better about it.
Adobe After effects is a good example of a fairly standard app that will happily chew through 8-12 gigs of ram when working on moderately complicated videos.
I also know people who work with fluid dynamics and the new workstations they bought for work have 48 gigs of RAM.
Think about what Adobe After effects is doing, though: non-linear video editing. A bit more than a decade ago, you couldn't do that outside of Hollywood. A bit more than two decades ago, and even Hollywood couldn't do it - everyone still used celluloid.
I'm not sure that either video editing or fluid dynamics count as bloatware in my book, because the problems are inherently complex. Word processing, however...
I did non-linear video editing on my PC in the late 90s. There were certainly some limitations since the AVI format was stupid (used a signed integer for an index limiting you to 2GB file size), but my machine then was a 133MHz pentium with probably 32 or 64MB of RAM. Granted I was only working with half-height VHS (640x240), but it worked.
I haven't tried a lot of video editing software today (since I no longer pirate software like I used to), but what I have used is not huge progress from what I did in the late 90s. The only big step is that you can work with compressed streams directly, which is nice, but expected since even a modest machine today is expected to be able to decompress the latest MPEG spec in realtime.
What are you putting in those tabs? I frequently have 50+ tabs open in Chrome and rarely get to more than about 1GB total. Sometimes some long running web apps will leak enough (Gmail, I'm looking at you...) to bring a single tab up in the 100-200MB+ range, but that's rare.
Comments
> every byte of RAM was precious as was every CPU instruction.
What I wouldn't give to infuse that sense in to present day programmers. (writing this on a box with 12G ram, pretty much maxed out).
Most of UNIX's utilities were written with high regard for their memory use. When GNU decided to clone them all, they actually outlined that their developers were forbidden to even review UNIX sourcecode. Convention stated that they all try to write the programs with speed in mind, and now we have these discussions.
http://www.gnu.org/prep/standards/html_node/Reading-Non_002d...
I don't think you should optimize for space or speed at each others expense without figuring out if the trade-off is worth it.
Space and speed will always be conflicting goals during optimizations (unless you're very lucky), and for practical use the sweet spot is usually somewhere in between the two extremes.
To blindly optimize for speed will result in very wasteful behaviour when it comes to memory usage, to blindly optimize for space will result in terrible performance.
Smart software realizes when the space is available and free for the taking and will use it to find an increase in speed, it will also realize when space is at a premium and economize on it's usage.
On another note, accessing all that memory costs cycles and is almost certainly going to trash your cache, chances are that if you manage to reduce your memory footprint eventually you'll find that instead of losing speed you're gaining speed.
Open Office started up with a blank word processor document uses 83 Megs of RAM, something tells me that could be a whole lot less without sacrificing functionality or speed.
I agree completely that one should not optimize for one area without taking in account the penalties incurred on the other areas. I hope I didn't give that impression.
One of the more major reasons of GNU developing the habit of writing utilities that were significantly different in their implementation was to make sure no UNIX/BSD code could leak in, since at the time the project was underway, BSD was stuck in that whole USL vs BSDi suit, and BSD's code was tentatively deemed 'non-free'.
One also needs to account for the time period these utilities were written, and for what computer system they were originally written for. Both memory and speed were expensive. Writing these utilities probably required much more thought to the smaller details than one would think about today when writing say a word processor, even though one could benefit by doing so.
> writing this on a box with 12G ram, pretty much maxed out
Serious question: what are you using 12G of RAM on? My workstation is pretty modest (core 2 duo, 4G RAM) and I'm rarely able to utilize more than 1G.
Having lots of memory can serve as a poor-man's SSD. At least on a Linux system files are read from the disk and left in memory until that memory is needed for something else. This can increase responsiveness by reducing the need to go to disk for frequently used filesystem data.
More info: http://www.linuxatemyram.com/index.html
The price of SSDs has come down sufficiently that you probably could say that having lots of memory is a stupid way to emulate having an SSD ;)
But the speed of RAM is still at least one order of magnitude faster than the SSD so there is still an advantage even with a faster fixed disk.
IDE, OpenOffice, Browser, email client, shell and window manager. That's it. The big ones are the first three and X windows.
I run exactly those apps on a computer with 2 gigs of RAM and never really had any problems.
We are probably doing different things with our applications.
Out of curiosity, how do you manage to make an IDE, Open Office and a browser eat through 12 gigs of RAM?
The stable version of Chrome leaks memory like crazy on Linux. I was frequently using over 1gb according to about:memory and have seen it use up to 3gb. 6.0.495.0 dev seems to be better about it.
It's really not that hard. One fair sized project and a bunch of browsers with tabs. It surprises me very much how much RAM that gobbles up.
I'm not even testing stuff with VMs right now, as soon as I get in to that I have to shut down the IDE at a minimum or I'll hit the swap.
a java ide?
Yep. Unfortunately.
Adobe After effects is a good example of a fairly standard app that will happily chew through 8-12 gigs of ram when working on moderately complicated videos.
I also know people who work with fluid dynamics and the new workstations they bought for work have 48 gigs of RAM.
Think about what Adobe After effects is doing, though: non-linear video editing. A bit more than a decade ago, you couldn't do that outside of Hollywood. A bit more than two decades ago, and even Hollywood couldn't do it - everyone still used celluloid.
I'm not sure that either video editing or fluid dynamics count as bloatware in my book, because the problems are inherently complex. Word processing, however...
I did non-linear video editing on my PC in the late 90s. There were certainly some limitations since the AVI format was stupid (used a signed integer for an index limiting you to 2GB file size), but my machine then was a 133MHz pentium with probably 32 or 64MB of RAM. Granted I was only working with half-height VHS (640x240), but it worked.
I haven't tried a lot of video editing software today (since I no longer pirate software like I used to), but what I have used is not huge progress from what I did in the late 90s. The only big step is that you can work with compressed streams directly, which is nice, but expected since even a modest machine today is expected to be able to decompress the latest MPEG spec in realtime.
Chrome uses some absolutely amazing 4-500MBs per tab. Had this box had less than 12GBs, I would rather be using the Firefox 4 betas.
What are you putting in those tabs? I frequently have 50+ tabs open in Chrome and rarely get to more than about 1GB total. Sometimes some long running web apps will leak enough (Gmail, I'm looking at you...) to bring a single tab up in the 100-200MB+ range, but that's rare.
Regular newspapers, facebook, reddit, hacker news, xkcd and dilbert.
That's about it.