- Android Studio itself: default heap size of 1280MB[1] plus ~400MB of metaspace
- Gradle: That's the part which surprised me the most:
- Most projects probably have a custom heap size set for Gradle. Turns out: If you're using Kotlin the same amount of heap size is also used for the Kotlin compile daemon. So if you configure -Xmx2G you'll end up with 2GB for the Gradle daemon and 2GB for the Kotlin compile daemon. The heap size for the Kotlin compile daemon can be separately configured by setting `-Dkotlin.daemon.jvm.options=-Xmx<xxx>`[2].
- Gradle 5.0 is way more memory efficient than the versions before and they even drastically lowered the default heap sizes[3].
- If you still have a custom heap size in your `dexOptions` set: that's not recommended anymore[4].
[1]: https://developer.android.com/studio/intro/studio-config
[2]: https://discuss.kotlinlang.org/t/solved-disable-kotlin-compi...
That's one of the reasons why some bloated contemporary desktop software (i.e. Slack) feels as fast as its historic counterpart did in 1995 (i.e. our MSN/ICQ clients back in these days).
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.
Because it's an Electron app, i.e. another copy of Chrome.
Actually for all the money they've raised I can't understand why the Slack apps are so terrible. I use Mac and iOS versions, and they still can't show useful activity badges; video doesn't work on ios...what are the spending their billions on?
As long as the software doesn't require all that memory, but can work OK with less and then scale up to use more if you've got it, I guess I don't see what the problem is.
It actually can. It's called swapping. An amazing technology from the 90s.
That's exactly the point of swapping. Memory which was not used in a (relatively) long time is taken away forcefully from the process if there is memory pressure on the system.
So it doesn't matter if Chrome releases it or not, it will be taken away if it just sits there.
To disk. Waiting for the memory a badly behaved app overzealously ate up without using to finish flushing to disk before being able to use it is worse than simply having the memory readily available. This is why I always disable swap, opting to let bad processes die, sometimes even pulling the trigger myself.
In modern systems, paging is okay. But not swapping.
From the 60s. Atlas computer had virtual memory. I originally thought it was the System360.
Yes, modern operating systems use free RAM as cache for the HDD. If you have an I/O intensive process, having a large amount of RAM is really helpful.
For that to work applications shouldn't be gobbling up all the ram, instead they should leave it to the OS to cache data.
Sure, NVMe drives help, but loading things from RAM is snappier still.
Also, those huge memory footprints themselves can also cause issues. E.g. they can increase GC pauses in GCed languages or decrease cache hit rates when allocations are scattered all over the place.
Cut corners and offload the trade-offs onto your end users.
It's so grossly dumb - giant native applications running a hidden web browser to show a webpage that does it utmost to pretend to be a native application (but it doesn't work - Alt-F to launch the File menu in slack but cursor left/right doesn't take you to the next menu like REAL native apps do)....
It's a future I do not wish to be involved with!
(Avoiding hardware upgrades isn't all peaches and cream. My graphics cards are getting less acceptable all the time, and I'll probably need to upgrade this year.)
I don't use Chrome or Slack or any of those others. The easiest way to use less memory is to not run programs which require a bunch of it. People who drive Ferraris don't complain about their fuel economy.
Repeat the cycle.
It means that however much you have, your system should use as much of it as possible. Otherwise it's just sitting there doing nothing. Contrary to popular belief, the more RAM you're using, the faster your system will be (assuming it's using the RAM efficiently)
Is this a joke? If I have 16GB of RAM but my programs use 18GB then my system will suddenly become faster?
If you work w/ removable media, IME the cache will free the pages associated w/ that media when it's removed (as the cache must be assumed invalid when/if the media is plugged back in). Playing a DVD, and then ejecting it, would often result in a large drop in disk cache. (Back before Netflix…)
>I'm not sure exactly what you are saying
> This is visible on all systems I work with (mac, win, linux), either attributed to the process, or to OS read cache.
My response was directed at your part of the comment:
>I would expect any system that manages cache data to fill most of your RAM.
All systems do that, but they don't look "used" (eg. on the windows memory graph, the dark region excludes os cached memory). Unless using free[1], no reasonable person would think 99% of their ram's being used.
hacking up and rebranding an IRCd is a tried and true startup method. Napster, Slack, Discord...
Use more sensible tools and you will not waste as much ram (firefox, visual studio code, .net)
Edit: Numberwang, apparently your account is dead so I can't reply anywhere but here.
Edge is great. I can't complain about its memory usage. Unfortunately with Microsoft moving to chrome engine, I am taking the precautionary measure of moving to Firefox until they have shown they can make Chrome suck less. Firefox is not as good as Edge for my needs, but quite close.
¹but I don't want to downplay this concern entirely; in the parent's case of an int needing boxing, that effectively doubles the cost: the int, and now the pointer to that int. (Plus any hidden requirements of the allocator, but even if we assume that's free, the story might still be plenty grim.)
Empty objects aren't free either, so you pay triple.
Does anyone know anything about the memory usage of Edge?
I use a bunch, like uBlock Origin, uMatrix, Tridactyl, Tree Style Tab, and Stylus, and Firefox slows down to a crawl for me when I have more than about 8 tabs open.
Now, some might advise not to use extensions, but using extensions is half the reason that I use Firefox at all in the first place, as Firefox without extensions really sucks.
Slack leaks memory like there's no tomorrow, but that's on Slack. I just close the Slack tab and force a full GC/CC cycle and I get my memory back.
I'd do a binary search of sorts, disable half of the extensions and see if performance is still bad or not etc, to narrow it down to the offending extension(s).
The only extension I use is uBlock Origin. I've never felt the need for anything else whether it's on Firefox or Chrome.
Geek culture has zero loyalty, otherwise people would run the product that has moral integrity even if it costs them a few milliseconds in load times.
This is objectively false.
Followed by Android Studio (3GB for a medium project), IntelliJ idea (another 3GB for a smallish project + 15% cpu constantly)
If prices keep going down i'll just put 128GB and call it a day.
Slack takes more than half a Gig with only 5 teams. It's a chat app, what the F?