Question: **Background**  

I revisited an old (but great) site I had not been to for ages - the Alioth Language Shootout ([http://benchmarksgame.alioth.debian.org/](https://web.archive.org/web/20130325171128/http://benchmarksgame.alioth.debian.org/)).

I started out programming in C/C++ several years ago, but have since then been working almost exclusively in Java due to language constraints in the projects I have been involved in. Not remembering the figures, I wanted to see, approximately, how well Java fared against C/C++ in terms of resource usage.

The **execution times** were still relatively good, with Java at worst performing 4x slower than C/C++, but on average around (or below) 2x. Due to the nature of the implementation of Java itself, this was no surprise, and it's performance time was actually *lower* than what I expected.

The real brick was the **memory allocation** - at worst, Java allocated:

* a whopping 52x more memory than C
* and 25x more than C++.

52x the memory ... Absolutely nasty, right? ... or is it? Memory is comparatively cheap now.

**Question:**  

If we do not speak in terms of target platforms with strict limits on working memory (i.e. embedded systems and the like), **should memory usage be a concern when picking a general purpose language today?**

I am asking in part because I am considering migrating to Scala as my primary language. I very much like the functional aspects of it, but from what I can see it is even more expensive in terms of memory than Java. However, since memory seems to be getting faster, cheaper and more plentiful by the year (it seems to be increasingly hard to find a consumer laptop without at least 4GB of DDR3 RAM), could it not be argued that resource management is becoming increasingly more irrelevant as compared to (possibly implementation-wise expensive) high-level language features which allow for faster construction of more readable solutions?

Answer: 
Memory management is utterly relevant since it governs how fast something appears even if that something has a great deal of memory. The best and most canonical example are AAA-title games like Call of Duty or Bioshock. These are effectively real-time applications that require massive amounts of control in terms of optimization and usage. It's not the usage per se that's the issue but rather the management.

It comes down to two words: Garbage Collection. Garbage Collection algorithms can cause slight hiccups in performance or even cause the application to hang for a second or two. Mostly harmless in an accounting app but potentially ruinous in terms of user experience in a game of Call of Duty. Thus in applications where time matters, garbage collected languages can be hugely problematic. It's one of the design aims of Squirrel for instance, which seeks to remedy the issue that Lua has with its GC by using reference counting instead.

Is it more of a headache? Sure but if you need precise control, you put up with it.
It depends on a number of factors, especially the scale at which you're working.

Just for the sake of argument, let's assume a 30x difference in memory and 2x in CPU usage.

If you're dealing with an interactive program that would take 10 megabytes of memory and 1 millisecond of CPU if written in C, it's pretty much inconsequential -- 300 megabytes of memory and 2 milliseconds to execute is normally entirely irrelevant on a typical desktop, and unlikely to mean much even on a phone or tablet.

The difference between needing around half the resources of 1 server and needing 15 servers is a *much* bigger step though -- especially since scaling out to 15 servers is likely to require a lot of *extra* work to develop instead of less. As far as future expansion goes, the same factors you mention tend to suggest that unless your customer base undergoes *massive* growth, that if it'll run on one server now, chances are pretty good that when you outgrow that server, you'll be able to replace that with one newer server without any problem.

The other factor you really need to consider is exactly how much difference in development cost you're going to see for your particular task. Right now, you're basically looking at one side of an equation. To get a good idea of costs vs. benefits, you (obviously enough) need to look at both costs and benefits, not just one in isolation. The real question is basically: "is x greater than y?" -- but you can't determine that by looking only at x. You clearly need to look at y as well.