191

If we look at the vintage program Netscape Navigator or an early version of Microsoft Word, those programs were less than 50 MB in size. Now when I install google chrome it is 200 MB and desktop version of Slack is 300 MB. I read about some rule that programs will take all available memory no matter how much it is but why?

Why are the current sizes of programs so large compared to 10 or 15 years ago? The programs are not doing significantly more functions and do not look very different. What is it that is the resource hog now?

Niklas Rosencrantz
  • 8,008
  • 17
  • 56
  • 95
  • 136
    Only 4 times the size?! That's amazing considering how much more a modern browser does – Richard Tingle Sep 24 '15 at 11:37
  • 23
    As a side note, i believe 'some rule that programs will take all available memory no matter how much it is but why?' probably refers to random access memory rather than physical disk space, at least that would be my interpretation of it. Could be wrong. – James T Sep 24 '15 at 13:40
  • Although I'm not totally sure of it, I'd bet that the Slack you mentioned has a full-suited web-browser packed into it. Making the program so big saves the company money in that they have only one codebase for the UI, not two separate. – Pavel Sep 24 '15 at 13:45
  • 1
    Programs often pull in lots of libraries. For example the .NET Framework is huge. Like 100MB of managed DLLs. Lots of coding monkeys have typed that in. – usr Sep 24 '15 at 14:08
  • 104
    So what you're saying is that a program that once took up $10 worth of hard disk space now takes up about 30 cents worth of hard disk space? I find this hard to worry about. – Eric Lippert Sep 24 '15 at 14:21
  • 10
    Don't forget that going from 16 bit to 64 bit architecture every integer constant in the program, every static pointer, and many processor instructions quadruple in size. – mustaccio Sep 24 '15 at 14:38
  • 49
    “The programs are not doing significantly more functions” — good lord man. Just take a look at [the HTML 4 spec](http://www.w3.org/TR/html4/) and [the CSS 1 spec](http://www.w3.org/TR/REC-CSS1/) (don’t worry, I’ll wait — it won’t take you long even if you read them). Netscape 4 didn’t even manage to implement those properly. Just the amount of new and crazy HTML and CSS that Chrome supports is considerable. Plus it has tabs. And updates itself every six weeks. – Paul D. Waite Sep 24 '15 at 22:29
  • 12
    I don't understand why Adobe Acrobat (that only creates pf documents) is bigger than many Operating Systems. And some CAD programs (such as Catia) take 30GB, it's just crazy. – skan Sep 25 '15 at 10:43
  • @PaulD.Waite better check for updates then, mine seems to update weekly. Are you referring to major stable versions? – MonkeyZeus Sep 25 '15 at 14:23
  • 9
    Ironically, this question was being asked even when Netscape Navigator was new. (When I started programming, sizes of 20-50K were common but that was for simple COBOL batch programs). – Alfred Armstrong Sep 25 '15 at 14:48
  • @mustaccio: maybe we should go to 1-bit CPUs... I wrote a 3 byte .COM program once (return with success / fail result code - used in batch programs). –  Sep 25 '15 at 16:01
  • 3
    Don't think it's that bad… Just downloaded, out of curiosity, Firefox (OSX version, for the record), and download clocked at 79,7 MB. – el.pescado - нет войне Sep 25 '15 at 17:15
  • 14
    BTW. 50 MB in Netscape times was large, but, for the record, it included not only web browser but also mail client and HTML editor, and maybe even something else. – el.pescado - нет войне Sep 25 '15 at 17:18
  • @skan Adobe Acrobat comes with Distiller, a [PostScript "Printer"](https://www.adobe.com/products/postscript/pdf.html) ([PS](https://en.wikipedia.org/wiki/PostScript) is a turing-complete language for describing documents as opposed to PDF which isn't). That can't be small. But what do you mean bigger than many operating systems? IIRC, it's less than a gig. Photoshop, OTOH, that's a behemoth – Cole Tobin Sep 26 '15 at 05:40
  • @ColeJohnson yes Photoshop is optimized in size and very good but Acrobat is not. – skan Sep 26 '15 at 11:18
  • 6
    Netscape Navigator was 50 MB? Holy Cow, that was humongous back in the day... – hyde Sep 26 '15 at 11:45
  • 3
    I think this question is good, but web browsers are a bad example since they increased significantly in functionality, It would be better to pick something which is functionally similar. – ideasman42 Sep 26 '15 at 14:42
  • The Slack client is basically a browser that opens the Slack page. So it includes a lot of possibly redundant code. – This company is turning evil. Sep 26 '15 at 15:00
  • @PaulD.Waite Having tabs is irrelevant. Opera 4 had tabs, and that was a **LOOOOOOOOOOOOOOOOONG** time ago. Before that, Opera supported MDI forms (a window within a window) since it's early versions. – Ismael Miguel Sep 27 '15 at 16:18
  • 4
    @IsmaelMiguel: yeah but Opera had everything first. – Paul D. Waite Sep 27 '15 at 16:35
  • Moore's Law, computers get faster, humans expect their computers to do more stuff, therefore more features. – Chris O Sep 27 '15 at 23:57
  • 1
    Why is your definition of "resource hog" only limited to disk space? Usually a resource hog uses too much CPU and/or memory. – Chris O Sep 28 '15 at 00:01
  • 1
    I once had a discussion about this with an old arcade developer. His response to why programs have become so much larger was essentially "because they can be". Modern developers don't have to be as concerned about every byte of code because in most instances, it's not really as much of a limitation any more. His philosophy: Make something that looks good, sounds good, is exciting and keeps people coming back, and do it in 4K. PacMan (or even Pong) may not look as good as any modern game, but I'd bet they've had more playtime than anything you'll see for a very long time. – Shawn Sep 28 '15 at 15:41
  • Many programs these days have large intermediate abstraction layers which make them easier portable, notably open source programs like browsers and office applications. Qt comes to mind. Probably also true for many mobile apps which target Android and iOS. These layers re-implement or at least wrap much of the native OS and graphics libs. [This should be an answer but I don't have enough rep.] – Peter - Reinstate Monica Sep 29 '15 at 10:11
  • 3
    I won't even bother to write this as an answer, since it will be down voted faster than you can read. The reason is that the quality of programmers just got worse today. A good developer automatically writes nearly optimal code. He might save ~10% of development time when writing non-optimal code, but he'll usually just refuse. A bad developer on the other hand will always write non-optimal code. He might be able to write marginally better code, but that will increase the time needed by two orders of magnitude. Just open any large project and actually look for yourself. And it's getting worse. – Andreas Sep 30 '15 at 16:08

15 Answers15

266

"Looking very different" is a matter of perception. Today's graphics have to look good at totally different screen resolutions than they used to, with the result that a 100x100 image that used to be more than good enough for a logo would now look horribly tacky. It has had to be replaced with a 1000x1000 image of the same thing, which is a factor of 100 right there. (I know you can use vector graphics instead, but that just emphasizes the point - vector graphics rendering code has had to be added to systems that didn't need it before, so this is just a trade-off from one kind of size increase to another.)

"Working differently" is likewise a matter of perception. Today's browser does massively more things than one from 1995. (Try surfing the internet with a historic laptop one rainy day - you'll find it's almost unusable.) Not many of them are used very much, and uses may be completely unaware of 90% of them, but they're there.

On top of that, of course, is the general tendency to spend less time on optimizing things for space and more on introducing new features. This is a natural side-effect of larger, faster, cheaper computers for everyone. Yes, it would be possible to write programs that are as resource-efficient as they were in 1990, and the result would be stunningly fast and slick. But it wouldn't be cost-effective anymore; your browser would take ten years to complete, by which time the requirements would have completely changed. People used to program with extreme attention to efficiency because yesteryear's slow, small machines forced them to, and everyone else was doing it as well. As soon as this changed, the bottleneck for program success shifted from being able to run at all to running more and more shiny things, and that's where we are now.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 120
    Concrete examples of things a modern browser should include would be crypto libraries, the Unicode database, a JavaScript runtime and optimizing JIT compiler, video codecs, a PDF renderer, in addition to a complicated rendering engine and parsers for all the supported MIME types. That does add up, but unlike games browsers don't require lots of high-res assets. A modern Firefox download only weighs 40–50MB compressed. – amon Sep 24 '15 at 08:01
  • 23
    "the result would be stunningly fast and slick" - sounds like wishful thinking. – Doc Brown Sep 24 '15 at 10:08
  • 16
    @amon Don't forget that browsers also include other type of resourses and an entire API for plugins and what-not. They even come with debugging tools (profilers, network analisers, element inspectors, a fully functional console, debuggers and a ton more). Browsers are getting closer to an entire operating system than we all can imagine. There's even an on-going discussion to use Web Assembly! The O.P. should be amazed by the ton of crap they can cram up in a browser. – Ismael Miguel Sep 24 '15 at 11:29
  • 10
    @IsmaelMiguel As far as Chrome OS is concerned, browsers already _are_ an entire operating system. ;-P – Ajedi32 Sep 24 '15 at 13:33
  • 111
    `tendency to spend less time on optimizing things for space ` This. When I write code, I don't optimize for space or speed. I optimize for maintenance. It's more important that the codebase can change easily than be fast or small. I can expect that for every complaint about program speed, I'll get ten requests for new features and zero requests to make it smaller. – user2023861 Sep 24 '15 at 14:03
  • 1
    I think browsers are an extreme example because the Internet has changed so much in the past 20 years. – Alex W Sep 24 '15 at 17:28
  • @AlexW So have operating systems and computers in general. – Shadur Sep 25 '15 at 07:02
  • 1
    `But it wouldn't be cost-effective anymore`. There are so many hidden assumptions in that one that I don't know what to stress. It has never been more cost-effective to do a resource-efficient program than to do a resource-wasteful program, even in the 90's. I'd even say that today's tools are more amenable to help programmers write resource-efficient programs than the ones we had in the 90's. C++1* to mention only three of them. Resource scarcity is coming back with the IoT. – Laurent LA RIZZA Sep 25 '15 at 10:03
  • 5
    100x100 → 1000x1000 is not a factor of 100 size increase. – Lightness Races in Orbit Sep 25 '15 at 10:59
  • 5
    I generally agree with your answer, but while reading it I got this irritating itch under my mind's skin because of statements like this: _"your browser would take ten years to complete, by which time the requirements would have completely changed"_ I really blame lazy culture of the new programmer generations for this. It's completely possible to write efficient, well-designed code without it taking ten years and without it taking long enough that your requirements mutate in the meantime: it's just that people don't _bother_ to diligently plan properly any more. They're mistaught, I suspect. – Lightness Races in Orbit Sep 25 '15 at 11:00
  • 6
    @LightnessRacesinOrbit: New generations are not mistaught. They're not taught at all. There are not enough veterans in the industry to teach the everincreasing flood of newcomers. There are not many people with 30+ experience because 30 years ago, there were not many programmers. – Laurent LA RIZZA Sep 25 '15 at 12:35
  • @LaurentLARIZZA: Heh, I was trying not to be _too_ harsh, but you're right :) – Lightness Races in Orbit Sep 25 '15 at 13:02
  • 1
    @LaurentLARIZZA: Actually on second thought I'll stand by what I said. Being mistaught is orders of magnitude worse than being not taught at all, and I maintain that criminally negligent misteaching is what's taking place at schools around the entire world (more so in some countries than in others, but still). Of course there _are_ also millions of self-"taught" wannabes who are a problem, too. – Lightness Races in Orbit Sep 25 '15 at 13:03
  • 2
    Maybe another way to look at it is, instead of optimizing for hardware resource usage, we optimize for developer productivity. – Brandon Sep 25 '15 at 18:17
  • 2
    Back in the day, [64k intros](https://en.wikipedia.org/wiki/64k_intro) proved that hardware could be slicker and faster than general mainstream developers would have you believe, and using far less code than a conventional application. Some of those programs were even written in a week or less using pure assembler. Unfortunately, as we all know, pure assembler isn't very portable, nor is it even commonly taught, *and* even if it were, each developer would have to be a masterful expert to get tasks done in a comparable amount of time as higher languages. – phyrfox Sep 25 '15 at 22:27
  • 1
    Because I'm not sure it can be worked into an answer rather than making for interesting reading, I'm leaving this as a comment: It's what happens when you neglect [the UNIX Philosophy](http://catb.org/esr/writings/taoup/html/ch01s06.html) – Agi Hammerthief Sep 25 '15 at 22:36
  • 6
    @LightnessRacesinOrbit 100x100 1000x1000 is basically a 100x size increase. Then there is compression, but compression kicks in the same for 100x100 and 1000x1000 – edc65 Sep 26 '15 at 10:13
  • @edc65: Oh, yes, you're right; I guess I was reading the original text as suggesting it were a 10x size increase. – Lightness Races in Orbit Sep 26 '15 at 10:57
  • @LightnessRacesinOrbit I've yet to see a single situation where "everything used to be better" was actually true and not just . All of those cool tricks people back then used generally made programs (1) non portable, (2) a maintenance nightmare and (3) security insensitive to the utmost degree. And heck in the 90s people used to say the exact same thing about programs written in the 70s. – Voo Sep 27 '15 at 12:30
  • @Voo: That's a strawman argument. I never claimed that "everything used to be better". I am just relating my wealth of personal experience and observations that show without a shadow of a doubt that young programmers are _not_ instilled with diligence and rational thought any more. I suspect it's due to saturation — there are far too many to teach nowadays. – Lightness Races in Orbit Sep 27 '15 at 13:04
  • 1
    @Lightness The plural of anecdote is not data. I'm sorry if you personally had bad experiences with some younger programmers, but that's it - anecdotes, nothing more. If you really claim that chrome is written by much lazier people than Netscape you should back that up with more. Because I du know people who work on those and in my also purely anecdotal experience they're just as hard working as their predecessors. – Voo Sep 27 '15 at 13:14
  • 2
    @Voo: Goodness gracious me. Having a bad day? Calm down please and humbly learn from the knowledge of those with more experience than you. Your logic is not sound either: of course there is still a variation in skill - there are still good programmers, and bad programmers. Some good ones today may be better than the average of yesteryear! That is _obvious_. But the average quality of teaching and of the skill pool has definitely deteriorated. If you don't want to believe that, that's your choice: I can't and won't make you. – Lightness Races in Orbit Sep 27 '15 at 13:15
  • @Lightness so you're saying it's obvious based on all the facts (i mean all those few dozen personal experiences) that the general teaching standard for millions of programmers has dropped compared to the days when CS was taught in math or EE institutes by people who themselves had no formal education? Stephen Colbert would term that truthiness. – Voo Sep 27 '15 at 13:21
  • @Voo If you spent any time _looking_ at the millions of lines of code produced the world over then you'd see the pattern, yes. – Lightness Races in Orbit Sep 27 '15 at 14:10
  • @Voo: Huh? You seem now to be talking about something completely different? – Lightness Races in Orbit Sep 27 '15 at 14:16
  • @Lightness It's pointless to argue with someone whose argument boils down to "my gut says so", even if I could show dozens of age old examples of lazy and bad design from the 70s - which again would be nothing more than anecdotes because to the best of my knowledge nobody has done any objective measures of software quality over the years (NASA and the DOD did some but limited in scope afaik). While I would like to be as adamant either way instead of saying "We don't have enough facts to know", as an engineer I'm not in the business of making absolute statements without any hard facts. – Voo Sep 27 '15 at 14:22
  • 1
    @Voo: I'm not making an "argument". I don't claim to present any data or a formal "proof". I'm just sharing my experience, views and observations. Most people would be interested and excited to share such things with other people, but you seem more interested in being contrary. For example, nothing whatsoever about what I've said has anything to do with such silly statements as "my gut says so". Oh well. At least we can agree that this conversation should not be taken any further. – Lightness Races in Orbit Sep 27 '15 at 14:25
  • 1
    @Voo One of the phenomenas Lightness is talking about is extremely well-known as "java schools". It's not just anecdotal. – Izkata Sep 27 '15 at 21:24
  • @LightnessRacesinOrbit This isn't a chatroom; this is a place many people go to find actual, hopefully correct information. Surely the standards are higher than a water cooler conversation, where your assertion without evidence belongs? If not, [Joel disagrees with you](http://www.joelonsoftware.com/articles/fog0000000017.html), and he at least brings cookies. – Alice Sep 28 '15 at 17:51
  • 2
    @Alice: Just because this isn't a chatroom doesn't mean I need to attach a ten-page dossier with a three-page list of references in order to pass along some relevant information in a comment. I don't know why y'all are being so defensive and rude over an innocuous statement relating to what is ultimately a well-known fact of our industry. – Lightness Races in Orbit Sep 28 '15 at 18:38
  • 1
    @LightnessRacesinOrbit Except it _isn't_ a fact, it's an _assertion_. One made without _evidence_. The one being rude is _you_, to a class of people and industry that does not necessarily deserve it. Extraordinary claims require extraordinary evidence, or did making baseless assertions without evidence somehow come back into vogue? – Alice Sep 28 '15 at 18:56
  • 2
    @Alice: I'll only say it one more time. No, it doesn't need "evidence". It's a comment. If I feel like presenting you with a research paper on the topic, rest assured I shall collect some data. For now, it's an observation made colloquially and, as such, your antagonistic response is completely absurd. Let's now drop the topic. – Lightness Races in Orbit Sep 28 '15 at 19:20
  • @LightnessRacesinOrbit It absolutely needs evidence, if it is to be taken seriously. Otherwise, it isn't merely a comment, _it is an unsubstantiated one_. It's absurd to attack an entire generation, both of people and industry, with not even a single bit of supporting evidence. I only attack you; you attack decades of the world. Which of us is the more antagonistic? – Alice Sep 28 '15 at 23:44
109

If you compare Netscape Navigator to a modern browser, there is a massive difference in functionality. Just compare the HTML 3.2 Spec (51 pages when I do a print preview) with the current HTML Spec (PDF version is 1155 pages). That's a 20x increase in size.

Netscape Navigator did not have a DOM and did not have CSS! There were no dynamic changes of the document, no JavaScript modifying the DOM or style-sheets. No tabs. No audio or video. A modern browser is a vastly more complex program.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 13
    Yes, recent browsers do animations, gradients, image filters effects, JavaScript, 2D graphics (canvas), 3D graphics with WebGL, Audio generation, Gamepad (!), Video decoding, advanced client-side-storage, Peer-to-peer communication (WebRTC), Geolocation, WebSocket, WebCryptography, MIDI, access to mic/webcam, notifications, etc. – ysdx Sep 24 '15 at 10:40
  • 1
    Add doing more stuff (DOM, CSS, Javascript) to also having more real estate (Multiple Monitors, massive increase in resolution: [Computer Screens Getting Bigger: 1999 through 2011](http://www.nngroup.com/articles/computer-screens-getting-bigger/) ) - 800x600 vs 1920x1080 vs 4k... 8k and beyond... 1080 to 4k is quadruple the resolution... 8k is quadruple again. – WernerCD Sep 24 '15 at 13:00
  • 7
    @WernerCD Simply having a bigger screen doesn't require a bigger binary. A 64 by 64 pixel, 32 bit icon will require the same amount of space on disk whether it's being displayed on an 800x600 or 2560x1440 monitor. Resizing your window doesn't change the size of the binary. What matters with displays is when you start doing stuff like pixel doubling, then you need bigger resources to continue looking sharp(er). – 8bittree Sep 24 '15 at 14:07
  • 1
    @8bittree, it can put a higher demand on the software performance. And more performant code can be more complex (e.g. a website using Canvas likely needs more complexity and code than one using SVGs). But yeah, you're mostly correct. – Paul Draper Sep 24 '15 at 14:19
  • @8bittree - yes, but too keep the visual quality while increasing resolutions and screen sizes you need larger assets and/or better optimising code. – Davor Ždralo Sep 24 '15 at 17:32
  • @DavorŽdralo No. Simply going from an 800x600 screen to a 2560x1600 screen does not affect visual quality. It simply allows you to see more. You only need larger assets when you start using a logical screen resolution smaller than the native screen resolution, such as the pixel doubling that Apple does with their retina displays, or the interface magnification in Windows. – 8bittree Sep 24 '15 at 17:45
  • 2
    While it is certainly true that current HTML does a lot more than HTML 3.2 did, the specification itself is also a lot more detailed which adds significant amount of content to the spec. Compare the length of [HTML 3.2's description of the `EM` element](http://www.w3.org/TR/REC-html32.html#phrase) -- a full eight or nine words -- with [the length of the same in the HTML 5 spec](http://www.w3.org/TR/html5/text-level-semantics.html#the-em-element) -- for me, more than a screenful including surrounding material describing the element, where it is applicable and what its intended use is. – user Sep 25 '15 at 09:31
  • Yeah, it's more to do with what the new specs add. For instance, one single new tag in HTML5 requires that browsers ship with a video player. – Gort the Robot Sep 26 '15 at 00:40
  • @8bittree Incorrect. If they have more pixels, but the same size screens (or if there is a shift that way at least), the icon that is 32x32 will look either blurry (because it is scaled up) or too small (because it is the same size). A larger pixel screen requires larger icons for this reason. – Alice Sep 28 '15 at 18:00
  • @Alice And most of the time, either the screens have been physically larger (compare 2560x1600 at 30in to 1280x800 at 15in), or the icons were, in fact, physically smaller (common with 1920x1200 at 17in). Only recently have we been moving towards using increased pixel count to make images sharper and keep things the same size, something I have repeatedly mentioned Apple's retina displays as an example of. – 8bittree Sep 28 '15 at 18:13
  • 1
    @8bittree Except the average size of monitors hasn't increased by that much, and there start to be diminishing returns over 30in. So your handwave doesn't really work. – Alice Sep 28 '15 at 18:17
  • @Alice What handwave? That 2560x1600 30in size is [something that exists](http://www.pcmag.com/article2/0,2817,1738301,00.asp) and predates the recent resolution semi-independence trend by several years. – 8bittree Sep 28 '15 at 18:24
  • @8bittree I never said it didn't exist, but my entire proposition is about the actual average shift, which is no where near what you are projecting. Just because something _exists_ doesn't make it _how most people view things_. Because most people are closer to 25in and 1080P, many icon/avatar sizes are now closer to 64x64 rather than 32x32 (or use vector graphics). – Alice Sep 28 '15 at 18:30
  • @Alice Actually, it [looks like more people](http://bobmckay.com/web/accurate-screen-resolution-usage-statistics-may-2014/) are closer to 1366x768. There's not going to be much scaling at that resolution for anything outside of pocketables. And 2732x1536 monitors are extremely rare, if they exist at all, so its not simply a case of pixel doubling. Anyway, this all ignores my original point that more pixels does not automatically mean bigger resources. I was trying to point out that more pixels can, and usually has, meant more usable space rather than a sharper (or blurrier) image. – 8bittree Sep 28 '15 at 18:43
  • @Alice Not to mention that with 1920x1080 at 20+ in, it's extremely unlikely that any scaling away from standard is happening, since 88-110 dpi is pretty close to Microsoft's standard 96 dpi from the 1980s. – 8bittree Sep 28 '15 at 18:54
  • For the record, Netscape Navigatro *did* support CSS (at least some subset of CSS1), *did* support dynamic modification of document via `` element, and *did* support sound (if I remember correctly ``). Geez, don't you remember all those home pages hosted on Geocities? – el.pescado - нет войне Sep 29 '15 at 06:44
  • @el.pescado: You are probably thinking of Netscape Communicator which superseded Netscape Navigator. The browser was called Navigator till version 3 and Communicator from version 4. Communicator did support some semblance of css though it invariably crashed if anybody actually tried to use it on a page, as far as I remember. – JacquesB Sep 29 '15 at 08:22
  • @JacquesB if I remember correctly, Navigator was web browser, while Communicator was whole suite, which included Navigator. – el.pescado - нет войне Sep 29 '15 at 09:23
80

One reason is that the data packaged within applications are larger because they are of higher resolution and quality. An icon back in the days of Netscape was at most 32x32 pixels, with at most 8 bit depth, (possibly only 4,) while now it is probably something like 64x64 and it is in true color with transparency, meaning 32 bit depth. That's 16 times larger. And space is so cheap that people often do not even bother checking the "compressed" option when generating a PNG.

Another reason is that applications nowadays carry a mind-boggling amount of data with them, which older applications did not. There exist applications today that get shipped together with a "getting started" presentation in video.

Another reason is that programming languages today tend to go together with rich run-time environments, which are fairly large, to the tune of 100MB each. Even if you do not use all of the features of your run-time environment, you still have to package the whole thing with your app.

But the main reason is that today there exist tons and tons of libraries out there that we can use in our applications, and we have developed a culture of using libraries as to avoid the constant re-invention of the wheel. Of course, once you start using libraries, several questions pop up, and we have developed the habit of giving the most liberal answers to them:

  • Is it worth to include yet another library if it is going to be used by only one of my functions? --yes.

  • Is it worth to include yet another library if I only need a tiny subset of the entire wealth of functionality offered by that library? --yes.

  • Is it worth to include yet another library if its inclusion will only save me from 2 days of work? --yes.

  • Is it worth to include multiple libraries that serve more or less the same purpose just because different programmers on my payroll happen to already be familiar with different libraries? --yes.

    (Please note that I am just observing these tendencies, I am making no statement whatsoever as to whether I agree or disagree with them.)

Another reason worth mentioning is that when trying to decide which application to use among several choices, some users think that the one which occupies more space will be more feature-packed, will have fancier graphics, etc. (Which is complete nonsense, of course.)

So, to conclude, does software behave like gas? Does it tend to occupy all of the space available to it? In a certain sense yes, but not to any alarming extent. If we look at what takes up most space on our drives, for most of us the answer is that it is not applications, but media such as movies and music by far. Software has not been bloating at the same rate that storage capacity has been expanding, and it is unlikely that it ever will, so in the future applications are likely to represent a negligible fraction of the storage space available to users.

Community
  • 1
Mike Nakis
  • 32,003
  • 7
  • 76
  • 111
  • 17
    This is the correct answer. The (presently) higher-rated comments mention more functionality, but that doesn't fully explain the increased size. The size comes from the included _libraries_ that provide those functionalities. – user1936 Sep 24 '15 at 13:39
  • 1
    `applications are likely to represent a negligible fraction of the storage space available to users.` --> Not when a single MMORPG game can eat up around 35GB on your harddrive. That's the equivalent to around 20 FullHD videos. And games now-a-days ocupy more and more space on disk. For a "*regular*" user, it is media stuff. For a gamer, surelly it is applications. For a programmer, maybe it is a mix of programs and media files. – Ismael Miguel Sep 24 '15 at 15:03
  • 5
    @IsmaelMiguel well, I was talking about regular users. Also, games are a special case, because these 35GB are mostly media, not code, nor libraries. It just happens to be media that you can only view via a special application, which is the game. But even for a gamer, 35GB are nothing on today's multi-terabyte drives. Anyhow, suppose that if you are a gamer who insists on owning a small drive then you are nowhere near representative of users out there. – Mike Nakis Sep 24 '15 at 15:08
  • 2
    @MikeNakis Not every gamer has a 1TB drive, or the money to buy a 256GB SSD. Some, like me, have a 128GB SSD, or a laptop with less than 500GB. A while ago, 80% of my SSD space usage was simply games. It was simply 3-4 games, eating the space. And in the game itself, almost everybody has a laptop and plays on it. – Ismael Miguel Sep 24 '15 at 15:19
  • @IsmaelMiguel: actually, in the game case, I would expect the vast majority of those dozens of GiB to *not* be application code but assets, i.e. media (sound effects, bitmaps, videos, background music, cutscenes). – Jörg W Mittag Sep 24 '15 at 22:25
  • @JörgWMittag Tera has a really low level of pre-rendered cut-scenes. And yes, the majority is just map files and collision files (damn you, invisible wall!) but it is still quite a lot. But, you are probably right. – Ismael Miguel Sep 24 '15 at 22:47
  • I agree with the general thrust of your statements, but I wonder about the libraries point. Is it common for people to statically link libraries today? Maybe I have just been programming Windows for too many years, but I always think in terms of dynamic linking (dlls) which does not increase the size of the main .exe in the same way. – Mike Sep 24 '15 at 22:56
  • 5
    @Mike oh, it does not matter. When we speak of the size of an application we mean either the size of the downloadable installation file, or the total space occupied by the application on disk once installed. This includes libraries, media, data, everything. And nowadays, in order to avoid incompatibility issues, applications usually ship together with most of the libraries that they need, instead of hoping that the libraries will be already installed, and be of the right version, etc. The size of the main executable file not really of any interest, nor of any consequence. – Mike Nakis Sep 24 '15 at 23:24
  • @MikeNakis Ah yes of course. Viewing size that way makes much more sense. – Mike Sep 25 '15 at 00:12
  • 3
    @IsmaelMiguel For a programmer, it's likely their different virtual machines, docker containers, and such. There is no better bloat than multiplying whole bloated systems ;-) – cmaster - reinstate monica Sep 25 '15 at 21:27
  • @cmaster Nothing like 2 Android 4.4.2 VMs and Windows XP with IE6 to cause massive bloat. – Ismael Miguel Sep 25 '15 at 21:30
  • @IsmaelMiguel *For a programmer, maybe it is a mix of programs and media files.* And for a programmer/sysadmin (sysprogrammer? progradmin?) it is virtual hard drive files for virtual machines. :) – BenjiWiebe Sep 26 '15 at 01:40
  • "Software has not been bloating at the same rate that storage capacity has been expanding" because it's in fact been bloating faster. Icons in phone apps have doubled from standard to Retina resolution which is 4x the pixels. Yet in the years between the iPhone 3G (first to ship with App Store) and the 6S, capacity on the entry level model only doubled from 8 GB to 16 GB. Nor have monthly download caps on cellular and satellite Internet increased much over the years. – Damian Yerrick Sep 26 '15 at 22:25
  • @tepples wow, you appear to be totally mobile oriented. I have no gripe with this, but the question is specifically about the desktop, so I think I am safe answering in terms of desktop only. – Mike Nakis Sep 26 '15 at 23:32
  • 1
    @tepples You also seem to be totally Apple oriented. I feel sorry for you, (and all Apple users,) because over the years I have replaced the Micro-SD card of my Android twice, doubling or quadrupling its capacity, for about €60. I could quadruple it once more now, ***again for the same money,*** and [go to 128GB](http://amzn.com/B010Q57S62), if it was not already time for a new device. I feel really sorry for all iphone users. Really. I am telling you, I am *devastated*. – Mike Nakis Sep 26 '15 at 23:35
  • @MikeNakis Windows desktop users outside the service area of cable and DSL, such as users in rural areas or urban Seattle, use satellite Internet or fixed wireless Internet, whose monthly cap hasn't kept pace with growth in software size. Windows laptop users use Windows desktop applications and may use cellular Internet when out of Wi-Fi range. – Damian Yerrick Sep 27 '15 at 01:11
  • @IsmaelMiguel http://store.steampowered.com/hwsurvey while you might be in the biggist single chunk, there there are more people above that. While not everyone has steam I'd guess a vast majority of gamers do have it – Gilsham Sep 27 '15 at 19:41
  • 2
    "now it is probably something like 64x64" - today [Apple](https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/Designing.html) advises creating icons sized up to 1024x1024px. – el.pescado - нет войне Sep 29 '15 at 06:47
  • 1
    Kudos for a great answer which takes a programmer's point of view as a perspective to explain OP's question. – Marco A. Sep 30 '15 at 16:11
17

In additional to the other ansers, 10 years ago there typically would have been separate versions for localised / internationalised versions. Now it's generally the case that programs will bundle full localisation support into every released version which pads the program size.

Eterm
  • 311
  • 1
  • 4
  • 6
    I may be wrong, but I'm laboring under the illusion that strings are the least part of this problem. True, there is a *lot* of languages out there, but still the amount of strings a user ever sees is *very* limited. After all, one of the surest way to fail at your user interface is to include too much text. – cmaster - reinstate monica Sep 25 '15 at 21:30
  • 6
    Adding to what @cmaster said, Firefox specifically does *not* bundle full localisation (and while I'm thinking about it, neither does OpenOffice.) – BenjiWiebe Sep 26 '15 at 01:41
  • 3
    @cmaster Strings, no. But localised video and audio, especially in the context of games? IIRC there was a 60 GB game (GTA V?) where >10 GB was solely localised audio. That's a significant chunk. – Bob Sep 27 '15 at 23:30
  • 1
    @Bob Right, I was not thinking about games, they seem to be the one big exception to what I wrote. – cmaster - reinstate monica Sep 28 '15 at 05:16
  • 1
    For each language, the string table might add up to a few extra K bytes. Just the application icons alone typically dwarf the total size of all string content (possible exceptions being applications with embedded dictionaries) – andyb Oct 03 '15 at 18:06
  • Yes, it's rather specialist software, but could still be a good example - my installation of Sibelius 6 includes ~50MB per language: UI strings, plugins, templates, examples, and - largest of all - handbook+reference PDFs. No audio or images or binary data of any kind as far as I can tell. Just 50MB of stuff that _contains_ language-specific text, where the entire language-independent remainder is 500MB. – Leif Willerts Oct 31 '21 at 15:49
13

One reason is dependencies. A program with rich functionality and good looks needs a lot of things done - encryption, spell checking, working with XML and JSON, text editing and lots of other things. Where would they come from? Maybe you roll your own and keep them as small as possible. Most likely you use third party components (MIT licensed open source perhaps) which have a lot of functionality you never actually need but once you need a single function from a third party component you often have to carry the whole component around. So you add more and more dependencies and as they themselves evolve and grow your program that depends on them grows too.

sharptooth
  • 4,349
  • 1
  • 27
  • 37
  • 1
    I'm kinda curious why this got two downvotes overnight. – sharptooth Sep 25 '15 at 07:46
  • 7
    I didn't but I don't think this really answers the question in sufficient depth. It pretty much just says "software gets bigger because it does more stuff", and you'll see from the other answers that there's really more to it than that. – Lightness Races in Orbit Sep 25 '15 at 11:32
  • 1
    A related factor is that in systems which use static linking, a linker may only need to pull in code which is actually used [some linkers would always pull in everything, but better ones tried to be selective]. When using dynamic linking, especially if modules can be shared, even if the first code that installs a module only needs one function from it, there's no way of knowing what functions may be needed by other code that wants to share the module. – supercat Sep 25 '15 at 17:09
  • @sharptooth I don't even wonder anymore. While in most cases the system works I also see horribly wrong broken answers get upvoted like crazy and accepted while the correct ones are downvoted into oblivion all too often... – Brian Knoblauch Oct 02 '15 at 14:11
11

While the graphics/usability are indeed contributing factors, there's an awful lot of it that's library/excess compiled code.

Example of how small code CAN still be: MenuetOS, a full 64-bit OS with powerful apps that fits on a single floppy disk.

Example of how big code can be for no obvious reason: I did a simple text output "Hello, World!" in Ada recently. The compiled executable was over 1 MiB!. Same executable in assembly is just a KiB or 2 (and the bulk of that is executable overhead, the actual running code is tens of bytes).

Brian Knoblauch
  • 4,170
  • 1
  • 17
  • 20
  • 3
    What's a floppy disk? ;) – 500 - Internal Server Error Sep 24 '15 at 19:42
  • 1
    @500-InternalServerError What is Ada? :D – BenjiWiebe Sep 26 '15 at 01:42
  • 4
    for newcomers, floppy disk is about 1.4 MiB – Display Name Sep 26 '15 at 07:51
  • 4
    I have seen modern Ada executables under 200 bytes. But if your compiler pulls in things like a full tasking runtime by default, whether you use tasks or not, then 1MB or so is to be expected. And it's not usually worth the bother of stripping it down. – user_1818839 Sep 26 '15 at 17:13
  • @BrianDrummond, sounds like a really crappy runtime, or a crappy runtime and library and linker. In a training video I saw many years ago, Jean Ichbiah et al mentioned that a typical Ada runtime (for the original version of the language) would be about 4K. Out of curiosity, I checked this against the TI 320C30 runtime package we were using. He was right on the money. – John R. Strohm Mar 10 '16 at 21:05
  • That was many years ago. Modern compilers and platforms just generate a lot bulkier code. Go find the post that's fairly widely circulated about things that Turbo Pascal (DOS) is smaller than. :-) – Brian Knoblauch Mar 22 '18 at 22:32
8

It's trivially true that software has to be built to fit two things: The users and the available hardware. A program is fit for its purpose if it does what the user wants in a timely manner with the hardware at the user's disposal. Well duh. But as hardware improves in basically all measurable dimensions the number of discrete programs which move from unfit to fit increases - the design space gets bigger:

  • Higher level languages make it possible to express ideas in less code & time than before. This lowered complexity, conversely, makes it possible to express increasingly complex ideas.
  • Bundling more data with the application can make it instantly more usable. For example, it probably won't be long before spell checking applications come bundled with every language known to humanity - it's only a few gigabytes, after all.
  • Hardware trade-offs allow developers and users more choice in which resource they care about. See for example FLAC/OGG vs WAV, SVG vs PNG, database indexes.
  • Humane interfaces often trade off what would previously amount to huge amounts of hardware for usability. Anti-aliasing, high resolutions, fast refreshing, and swiping between what amounts to discrete panels all make for a more realistic, and therefore intuitive and relatable, experience.
l0b0
  • 11,014
  • 2
  • 43
  • 47
6

This is definitely true concerning Android applications. Four years ago, a simple app took about 2-5 megabyte space. Nowadays a simple app takes about 10-20 megabyte space.

The more space available, the bigger the app size.

I think that there are two main reasons in case of Android:

  • Google expanded the Android framework, added a lot of new functionality.

  • Developers do not care anymore. Images are included in a far higher resolution (of course the smartphone screen resolutions increased), third-party libraries are thoughtlessly included.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Mike76
  • 205
  • 1
  • 4
  • 2
    That last bullet point is exactly right. – Lightness Races in Orbit Sep 25 '15 at 11:32
  • 4
    I've made a total of one android app, and the APK is 0.05MB. Then again, it doesn't do that much. I'm still wondering why a stopwatch app (with a similar amount of functionality as mine, though completely different) takes several MB. – user253751 Sep 26 '15 at 12:15
  • 6
    The last bullet point is wrong, developers *do* care. We just have to juggle various priorities and making that app a little bigger makes sense. – NPSF3000 Sep 26 '15 at 23:35
  • 1
    It also didn't help that the SDK (at the time) insisted on adding a 5+MB library to my 0.05MB app that I didn't need, and I had to remember to remove it before a release build. – user253751 Jul 24 '18 at 00:41
5

A lot of it boils down to developer time and the cost of that time. Back in the days when Visual Basic first arrived on the scene, it was competing with C/C++ and the big knock against it was that you could write 'Hello World' in ANSI C for Windows in maybe 15K. The problem with VB was you always had the albatross of the 300K runtime library.

Now, you could 10x the size of your VB program and it would still be just a few K more, but 10x the size of your C/C++ program and you're looking at a few MONTHS more development.

In the end the bloat of your applications is a small price to pay for the huge leaps in development production, reduction in price and sheer vastness of capabilities that would have never been possible in the old hand-crafted days of development; when programs were small and fast but also weak, incompatible with each other, under-featured and costly to develop.

Daniel Hollinrake
  • 740
  • 1
  • 5
  • 13
andyb
  • 124
  • 2
  • 2
    this post is rather hard to read (wall of text). Would you mind [edit]ing it into a better shape? – gnat Sep 25 '15 at 07:18
  • 1
    "10x the size" of Hello World requires "months more development"? Does brushing your teeth ten times involve standing in front of a mirror nonstop for a month? – bcrist Sep 29 '15 at 06:50
  • 1
    Brushing teeth x times is a linear function of x, but programming generally isn't a linear function. If you handcraft every line of code using the most low level language functions you get fast and small code but at a higher cost per level of complexity. Higher level languages bloat more but keep the cost closer to a linear function of the complexity. – andyb Oct 03 '15 at 17:59
2

By time, user's needs are evolving and more and more demanding, so vendor/authors of different softwares are forced to satisfy those needs in the name of competition.

But satisfying a new need means often adding new code. New code means new vulnerabilities to fix. Fixing new vulnerabilities may add code or open doors to new vulnerabilities.

Each added feature to satisfy a user's need may need more processor power for speed (we all complain about the speed of this or that browser), new graphical resources for better visual effects...etc.

All this means adding new layers of applications (code), security and sometimes hardware.

1

A lot of the size comes from built in libraries. Many applications these days are built using electron which bundles a huge amount with the application. If you install applications on Linux they are usually much smaller because much of the application is already installed through shared libraries that other programs are also using.

Qwertie
  • 496
  • 3
  • 14
0

When constructing software, if you need function A, you will import a module A*. A* can solve A, but A* can solve problems more than A, and A* could be large. All the large modules result in the large-sized software.

Maybe not the same case, but something like this: If you just need to print "hello world" on console using Java, you need JRE(>60MB) installed.

If the example of Java is not good, try this one: If the software need to logging to file, it may use a logging module which can actually make logs to database, over network and some other features, but the functions are never used in the project.

neoedmund
  • 147
  • 2
  • Why exactly there are 5 downvotes and not a single comment explaining why? – Kromster Sep 26 '15 at 17:54
  • 1
    @KromStern The first section greatly glosses over how libraries work, and does so in a very unclear way with inconsistent use of `code`. I would contend that it doesn't really answer the question at all. The second section uses Java as an example (though trying to claim that the JRE should be considered part of the growth of the application size - which again misses the point of the question and isn't a fair example at all and continues to perpetuate the misunderstandings of Java). All in all it is either wrong, or repeats points in previous, better written, answers. –  Sep 27 '15 at 01:04
  • 1
    Your example of logging to the network or file is not a good one either - because from the code's viewpoint, both are files and handled *exactly* the same way (the distinction between file and network is handled by the operating system). I have yet to see a logging framework that has "log to the database" as part of its core functionality as this would be complicated by Oracle vs MySQL vs Sql Server vs Postgres vs ... drivers and dialectical differences. –  Sep 28 '15 at 13:46
  • @user40980 The distinction between the file and the network is not handled by the operating system. They need different OS calls to connect to and write to. Database access is handled through a database independence layer like JDBC or libdbi. (Which in turn may pull in drivers for all the different supported databases!) – user253751 Jul 24 '18 at 00:46
-2

I read about some rule that programs will take all available memory no matter how much it is but why?

That's not quite true. Systems will not release memory they have consumed until the operating system comes under memory pressure. This is a performance improvement. If you were browsing a page with images on, you navigate away. You might navigate back, therefore needing the image again. If the operating system has the RAM there is no point in clearing the memory until you are sure you won't need it again.

Clearing the memory immediately would take CPU cycles and memory bandwidth away from the user when they are probably most likely wanting highly responsive web pages to be displayed on screen.

The operating system will consume all available non application memory, the majority of which is for the file system cache.

Memory management is a hard problem but there are very clever people working on it all the time. Nothing is being wasted on purpose and the key goal is to provide you with a very responsive computer.

Phil Hannent
  • 391
  • 3
  • 6
  • 3
    That is not at all what that saying is about. Virtual memory and garbage collection had just been invented when that quote was written, and they weren't widespread. – Jörg W Mittag Sep 24 '15 at 22:40
-2

It may be true that programs tend to expand to fill available space, similar to the suburban phenomena where you add new lanes to a gridlocked superhighway and within a few years traffic is backed up again.

But if you look into it you may find that they programs actually do more stuff. Browsers, for example, run fancier graphics, have slick developer tools that did not exist a few years ago, etc. They also link to many libraries, sometimes using just a small portion of the code. So while programs may increase in size to fill available memory, some of that may be fore legitimate reasons.

Paul J Abernathy
  • 155
  • 1
  • 1
  • 5
  • 2
    this doesn't seem to offer anything substantial over points made and explained in prior 13 answers – gnat Sep 28 '15 at 21:41
-3

Libraries built on objects that are not optimized require more memory to load, install, and more computing cycles to operate. Object code is for the most part bloat.

Just step through standard C++ code running to see all the assert()ed object calls to make sure they are valid objects. When you design layer upon layer of objects encapsulating objects the underlayers are bloated and opaque. Programmers get lazy and take on more objects because it's faster than redesigning what is limited to the needed functionality. It's really that simple.

Consider the size of the Linux C kernel, just the kernel, versus the size of bespoke applications. The kernel can run the entire machine. But it wasn't built as quickly as applications, it takes time slowly to make the best functionality.

daemondave
  • 164
  • 4