Side note, lessons from HPC aren't really that applicable for chat programs.

We increase memory usage for faster software development.

I’m totally with you for things that are actually doing serious numeric/algorithmic work. Matrix inversion runs a helluva lot faster when the whole matrix fits in RAM. And there are undoubtedly lots of places where you can use different algorithms for the same problem that can trade off memory usage and computational complexity.

But yes, running another browser + javascript interpreter on a machine that already has a browser + javascript interpreter running isn't what that article is talking about.

Adding memory often makes an entire system faster (again, because you can cache things in the faster RAM rather than paging out to disk). But for two comparable programs, I could see the argument that the lower-memory footprint program would be faster. (For comparable programs).

Often the memory being used is doing things like pre-loading information from disk or the network before it's needed, or caching results for reuse.

Or it's storing the information in a faster but less dense data structure - kind of like denormalizing a database for performance reasons.

Historically, under some circumstances, a problem compiled with -Os, may paradoxically be faster than -O2, and -O2 may be faster than -O3. I think the situation is getting better now, and the optimizing level mostly works as advertised. But there's still some problems in automatic loop vectorization.

The solution is to use abstract, arbitrary vectors in the ISA instead of packed SIMD and unrolled loops. RISC-V gets this right with their V extension.

Chrome is a big application that tries to be everything for all people. If Desktop performance mattered to companies, folks would strip out the browser and use native components. (This is literally React Native on mobile, even if programmers are still mostly writing in JavaScript instead of C++ or Objective C or Swift.)

This is just not true in a lot of ways.

For example, you can use memory to store the same data in multiple ways, and then you get blistering fast access, whereas if you only store it in a single way, you may get a range of read performance between "as good" to "really really bad".

I understand why what you said sounds true, but it's not that simple at all.

A very common tradeoff we make is to cache the results of time consuming calculations in memory, or even cache raw data in memory to avoid database calls. Both of these techniques increase memory usage, but improve performance.

Not if the alternative to reading/writing from RAM is reading writing from disk. One piece of data processing software I used to use had its roots in the early 80s and was very memory efficient. It achieved this by rewriting the input data to disk in a clever way and the reading and writing just the parts it need. I could process gigs of data using only a couple of hundred MBs of RAM. A different, more modern, program I also used would slurp in as much data as it could fit in RAM and then just go from there. It would happily use 30 of the 32 GB or RAM I had every time it ran, but it was also 1-2 orders of magnitude faster.

Hi, there's this guy named 'cache' that wants to speak with you.