What makes applications eat a lot of memory?

That's not a simple question - and it doesn't have a simple answer!
A lot of it will depend on the language you are using: C and C++ use pointers a lot, and if an app doesn't "clean up" when it is finished with memory, then it can't be reclaimed, and the memory used rises with time.
But C# and VB don't (they can, but it's difficult and not at all normal for a general purpose app - I haven't used a C# pointer in anger since I started with the language!) Instead, they use Reference (as does Managed C++) and that includes a Garbage Collector which recovers unused memory when you are finished with it - but only when the actual memory is getting low. It doesn't bother unless it needs to, because it takes time and your app must "wait" while it does it.

So there isn't a single reason: it may be that the app loads a lot of stuff to cache it, so it works faster once the app is fully started instead of going to a DB each time; it may be that it loads a lot of images (which take considerable space); it may be that the developer doesn't know what he's doing and allocates huge amounts on memory he doesn't need!

Basically there are as many reasons as there are applications! :laugh:

As explained in previous solution, there are numerous reasons why an application may consume a lot of memory. When creating an application, you can control some of the reasons but some you can't. For example if you use a badly designed driver that causes the memory consumption.

As a developer you need to take care that you don't store unnecessary things in memory and release the memory when not needed anymore. For example, If you're developing with C#, one thing is that you should take care that references that are not needed any more are properly released and objects are disposed when applicable. This way you take care that garbage collector can remove unused objects from memory. You can dive into more details at Garbage Collector Basics and Performance Hints[^]

Also development environments often offer tools to investigate memory related issues among other things. For example Visual Studio has a lot of capabilities to investigate memory consumption. For details have a look at Analyze Memory Usage in Visual Studio - Visual Studio | Microsoft Docs[^]

Quote:

What makes applications eat a lot of memory?

There is no standard answer to this because every single application have its own reason to eat memory.
The reasons range from real need, because of what the app does, to bad design and anything in between.

The elephant in the room is poor design and poor coding practices. It doesn't matter if the problem originated in third party software or in locally produced software.

Five decades ago, I was required to design and code software that fit in 320K bytes of memory. Up through 2000, significant constraints were placed on size and time complexity of the software I produced. Perhaps because much of it was mission critical real-time software. Perhaps because my customers demanded a 50% reserve in both computational speed and memory usage.

But in all cases, to solve the problems with which I was faced, I needed to be aware of current research in software practice and experience. I had to be a member of the Association for Computing Machinery (misnamed because it really had little to do with hardware) or the IEEE Computing Society. I had to actively participate in the publishing of my practice and experience. But most importantly, I had to submit my work to my colleagues and peers from whom I received guidance and the occasional encouragement.

So what's the reason we have the current state of affairs. Simply poorly trained programmers; poorly trained managers; rampant unprofessionalism. What can you do? You can only correct the problems that you yourself generate. So don't generate any. Solve software problems in the simplest way possible. Seek the advice of more senior programmers (with more than 20 years experience). Perform research (the problem that you are currently solving has probably been solved a number of times and, hopefully, the results will be published). Be critical of solutions that you find online. Seek out trusted colleagues to review your design and code. Always spend time to design a solution (don't just rush in and code).

And lastly, good luck.