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?

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

  • 134
    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 Trotter Sep 24 '15 at 13:40
  • 103
    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
  • 49
    “The programs are not doing significantly more functions” — good lord man. Just take a look at the HTML 4 spec and the CSS 1 spec (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
  • 13
    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

15 Answers 15


"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.

  • 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 8: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
  • 110
    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

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.

  • 12
    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 ) - 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
  • 1
    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 -- a full eight or nine words -- with the length of the same in the HTML 5 spec -- for me, more than a screenful including surrounding material describing the element, where it is applicable and what its intended use is. – a CVn Sep 25 '15 at 9:31

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.

  • 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
  • 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
  • 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
  • 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 Sep 25 '15 at 21:27

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.

  • 5
    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 Sep 25 '15 at 21:30
  • 5
    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 1:41
  • 2
    @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
  • @Bob Right, I was not thinking about games, they seem to be the one big exception to what I wrote. – cmaster Sep 28 '15 at 5:16
  • 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 3 '15 at 18:06

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.

  • I'm kinda curious why this got two downvotes overnight. – sharptooth Sep 25 '15 at 7:46
  • 6
    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 2 '15 at 14: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).

  • 3
    What's a floppy disk? ;) – 500 - Internal Server Error Sep 24 '15 at 19:42
  • @500-InternalServerError What is Ada? :D – BenjiWiebe Sep 26 '15 at 1:42
  • 3
    for newcomers, floppy disk is about 1.4 MiB – Sarge Borsch Sep 26 '15 at 7:51
  • 3
    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. – Brian Drummond 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

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.

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.

  • 1
    That last bullet point is exactly right. – Lightness Races in Orbit Sep 25 '15 at 11:32
  • 3
    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. – immibis Sep 26 '15 at 12:15
  • 5
    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
  • 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. – immibis Jul 24 '18 at 0:41

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.

  • 2
    this post is rather hard to read (wall of text). Would you mind editing it into a better shape? – gnat Sep 25 '15 at 7: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 6:50
  • 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 3 '15 at 17:59

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.


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.


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.

  • 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. – user40980 Sep 27 '15 at 1: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. – user40980 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!) – immibis Jul 24 '18 at 0:46

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.

  • 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

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.

  • 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

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.

protected by Community Sep 25 '15 at 7:03

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.