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: 
> 
> The real brick was the memory allocation - at worst, Java allocated a
>  whopping 52x more memory than C, and 25x more than C++.
> 
> 
> 

Do you *understand* the numbers you base your question upon? 

* How much memory was allocated?
* What were the programs doing?

When there's a big disparity between those Java and C programs, it's mostly the **default JVM memory allocation** versus whatever libc needs:

* n-body  

Java program 13,996KB :: C program 320KB :: Free Pascal 8KB

Look at the tasks that do **require memory** to be allocated (or use additional buffers to accumulate results from multicore programs):

* mandelbrot  

Java program **67**,880KB :: C program **30**,444KB
* k-nucleotide  

Java program **494**,040KB :: C program **153**,452KB
* reverse-complement  

Java program **511**,484KB :: C program **248**,632KB
* regex-dna  

Java program **557**,080KB :: C program **289**,088KB
* binary-trees  

Java program **506**,592KB :: C program **99**,448KB

> 
> ...should memory usage be a concern when picking a general purpose
>  language today?
> 
> 
> 

It depends whether the **specific** usage, for your **specific** approach to solving the **specific** problems you need to solve, will be constrained by the **specific** limits of available memory on the **specific** platform that will be used.
Memory management is **absolutely** relevant in today's world. However, not in the way you might expect. Even in garbage collected languages you have to ensure you don't have a reference leak

You're doing something wrong if this is your code:

```
static List<string> Cache;

...
Cache.Add(foo); //and then never remove anything from Cache

```

Garbage collection can't magically know you will never use some reference ever again unless you make it so you **can't** use it again, ie by doing `Cache=null`, you effectively alert the garbage collector that "hey I'm not going to be able to access it anymore. Do what you will with it"

It's more complicated than that, but reference leaks are just as, if not more, harmful than traditional memory leaks. 

There are also some places where you can't fit a garbage collector into. For instance, the ATTiny84 is a microcontroller with 512 bytes of code ROM, and 32 bytes of RAM. Good luck! That's an extreme, and probably wouldn't be programmed in anything but assembly, but still. Other cases you might have 1M of memory. Sure, you could fit a garbage collector, but if the processor is very slow (either by limitations, or to preserve battery), then you're not going to want to use a garbage collector cause it's too expensive tracking what a programmer *could* know. 

It also gets significantly more difficult to use garbage collection when you need guaranteed response times. Like, if you have a heart monitor or something and when it receives a `1` on some port, you need to guarantee you can respond to it with a proper signal or something within 10ms. If in the middle of your response routine the garbage collector needs to make a pass and it ends up taking 100ms to respond, that might be someone dead. Garbage collection is very difficult, if not impossible, to use when timing requirements need to be guaranteed. 

And of course, even on modern hardware, there is some cases where you need that extra 2% of performance by not worrying about the overhead of a garbage collector.