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.
To be fair, a lot of Java out there indulges in some truly and pointlessly class-explosive patterns that just murder performance and hog memory but I do wonder how much of that memory is just the JVM which in theory (heh) let's you run the same app in multiple environments without having to completely rewrite new ones. Hence the design tradeoff question it all boils down to: "How much of your users memory is such a development advantage worth to you?"

This is, IMO a perfectly worthwhile and reasonable tradeoff to consider. What pisses me off though is the notion that because modern PCs are so powerful and memory is so cheap, we can completely ignore such concerns and bloat features and bloat code and be lazy about choices to the point where it seems like a lot of the stuff I do on a windows PC now, takes just as long as it did in Window '95. Seriously though, Word? How much new crap that 80% of their user-base actually needs could they have possibly added in 18 years? Pretty sure we had spellcheck pre-windows right? But we were talking memory which is not necessarily speed if you have plenty of it so I digress.

But of course if you can get the app done in 2 weeks at the cost of maybe a few extra megabytes rather than 2 years to get the needs-only-a-few-K version, it's worth considering how a few megs compares to (I'm guessing) 4-12 gigs on the average users machine before scoffing at the idea of being so sloppy.

But what does this have to do with Scala beyond the tradeoff question? Just because it's garbage collection, doesn't mean you shouldn't always be trying to think about the flow of data in terms of what's in scopes and closures and whether it should be left sitting around or used in such a way that it will be deallocated by GC when it's no longer needed. That's something even us JavaScript UI web devs have had to think about and hopefully will continue to as we spread into other problem domains like the perf-savvy cancer (that you all should have killed with Flash or Applets or something when you had the chance) that we are.