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.
As with all things, it's a trade-off.

If you are building an application that is going to run on a single user desktop and can reasonably be expected to control a large fraction of the RAM on that machine, it may be worth it to sacrifice memory usage for implementation speed. If you're targeting that same machine but you're building a small utility that is going to be competing with a bunch of other memory-hungry applications that are running simultaneously, you may want to be more cautious about that trade-off. A user may be fine with a game that wants all of their memory when it's running (though, as World Engineer points out, they'll be concerned if the garbage collector decides to pause the action periodically to do a sweep)-- they are likely to be much less enthused if the music player they run in the background while doing other things decides to gobble up a ton of memory and interferes with their ability to work. If you're building a web-based application, any memory you use on the servers limits your ability to scale out forcing you to spend more money on more application servers to support the same set of users. That can have a major impact on the economics of the company so you may want to be very cautious about making that trade-off.