Hacker News Reader

Comment by ianhowson | Hacker News Reader

I don't think retain/release perf has anything to do with memory consumption, but I have seen a bunch of reviews claiming that 8GB is perfectly fine.

This is fascinating to me, because:

(a) every 8GB Mac I've used in the past has been unusably slow

(b) since upgrading my 32GB Hackintosh to Big Sur, my usual 40GB working set is only about 20GB.

(c) My 2015 16GB MBPr with Big Sur is also using about half as much physical memory on the same workload. Swappiness is up a little, but I haven't noticed.

So my guess is that something in Big Sur has dramatically reduced memory consumption and that fix is being commingled with the M1 announce.

View on HN

Every 8gb mac I’ve used before was fine, and that was with running Xcode, Firefox, photoshop, mail, terminal, and other programs.

4GB MBA user here, don't have any problems either running Chrome or Firefox with 10-20 tabs and iTerm (Safari does feel much faster than other two and my dev enviroment is on a remote server though).

Seriously, I'm utterly baffled by all the people claiming that 8 GB isn't enough for the average user.

The only situation I ever ran into where it was a problem was in trying to run multiple VM's at once.

Otherwise it's just a non-issue. Programs often reserve a lot more memory than they actually use (zero hit in performance) so memory stats are misleading, and the OS is really good at swapping memory not touched in a while to the SSD without you noticing.

Yes, sometimes it takes a couple seconds to switch to a tab I haven't touched in Chrome in days because it's got to swap it back in from the SSD. Who cares?

> people claiming that 8 GB isn't enough for the average user

I'm not claiming anything of the sort.

My point is that memory consumption seems to be greatly reduced in Big Sur, and that might make 8GB machines much better to use than before. All of my testing is on Intel machines. It's not exclusively an M1 phenomenon.

I would still recommend 16GB to anyone, and if the extra $200 was a factor, I would recommend that they buy last year's Intel with 16GB of RAM.

> I'm not claiming anything of the sort.

You kind of did:

> (a) every 8GB Mac I've used in the past has been unusably slow

Personally, I stick to 16GB+ as well. Though my wife's Mac likely has 4GB since it's something like 8 years old and it runs just fine.

For me with 16GB in an MBP, there is currently 20.5GB used + swap, and I haven't even started Firefox today, that would add another ~6GB or so.

Usually if I'm running Safari, Firefox and my 4GB Linux VM, that's 16-18GB used up in those. At the moment I have a few other things open, PDF viewer, Word, iTerms, Emacs etc, but nothing huge.

Most of the time this level of usage is ok, but I've had times where I've had to wait 30+ seconds for the UI to respond at all (even the Dock or switching workspaces) and wondered if the system had crashed.

For that reason I'm generally waiting for the next 32GB model before committing, that's assuming I stick with Apple instead of switching back to Linux (which I used for ~20 years before trying the MBP).

I pretty much daily have to do a closing round to not run out of my 24GiB. That’s all web browsers (Usually 100-200 tabs), vs code with some extensions and 2x4k display.

But what do you even mean "run out"? This is what I don't get.

If you have multiple browsers with hundreds of tabs, the majority of those tabs are probably swapped out to your SSD already.

With swapfiles and SSD's, physical memory is less and less relevant except when you're performing very specific computational tasks that actually require everything to be simultaneously in memory -- things like highly complex video effects rendering.

How do you measure "running out" of your 24 GiB? And what happens when you do "run out"?

As a human, when I have many tabs open, I observe that everything gets really slow. All applications get slow, but especially the browser.

So I put on my engineering hat and pull up Activity Monitor and further observe (a) high memory pressure, (b) high memory consumption attributed to Chrome or Firefox, (c) high levels of swap usage, (d) high levels of disk I/O attributed to kerneltask or nothing, depending on macOS version, which is the swapper task.

I close some tabs. I then observe that the problems go away.

Swap isn't a silver bullet, not even at 3Gbytes/sec. It is slow. I haven't even touched on GPU memory pressure which swaps back to sysram, which puts further pressure on disk swap.

It's slow.

I don't swap. You can do all your arguments about why I should if you want but yes, there are legit reasons not to and there is such a thing as running out of memory in 2020.

That's fine for you, but then it's disingenous for you to post your example without mentioning that.

It makes it unrepresentative and doesn't contribute anything useful to the conversation about memory requirements for normal operation.

It's the equivalent of having 50 stacks of paper documents & magazines sitting unorganized on your desk and complaining about not having space to work on.

A bigger desk is not the solution to this problem.

Some of us like our big loaded desks! No one really complained in this thread, just saying some of us will utilize a lot more memory than others.

If your tabs are swapped out to SSD, your computer feels incredibly _slow_. SSD are fast, yeah, but multiple orders of magnitude slower than the slowest RAM module.

You can run 4GB if you're fine with having most of your applications swapped out, but the experience will be excruciating.

Physical memory is still as relevant as it was 30 years ago. No offense but if you can't see the problem, you probably have never used a computer with enough RAM to fit everything in memory + have enough spare for file caching.

> Seriously, I'm utterly baffled by all the people claiming that 8 GB isn't enough for the average user.

I may be not average, but just my Safari can take up >20GB—at least that's how much my "free" grows in MenuMeters when I quit it.

It's the never ending mystery of Hacker News- how do the commenters on here get their computers to run so slowly?

Docker and a few language servers can seriously drag your MacBook with 8GB RAM. Throw in another Android emulator...

> Programs often reserve a lot more memory than they actually use (zero hit in performance) so memory stats are misleading, and the OS is really good at swapping memory not touched in a while to the SSD without you noticing.

The stats are absolutely reliable because no physical memory page is allocated until it is actually used to store something. So allocating a large chunk of unused memory wouldn't show in the (physical) memory usage stat.

> Otherwise it's just a non-issue.

Nah, sorry, but you're wrong. I had to upgrade my laptop because I wanted to run Firefox, IntelliJ IDEA and an Android emulator on the same machine. Nothing else. This was not possible on 8GB ram.

So it's not like multiple VMs are needed and above scenario is pretty average for a common mobile developer (but still not an average user, I admit)

Second thing is, lots of games require 16 GB RAM. Maybe gamers are still not average users, I don't know.

> an Android emulator

Well, that's one (largish) VM.

Large? It uses 1.5GB of RAM on average. Common Windows VM uses 6GB if you want it to be able to run a common application on it.

Have you tried doing Android dev using an Android emulator on an 8 GB Mac? Perhaps in combination with Xamarin?

I did and performance was horrible. For just iOS or macOS dev, 8 GB could be fine though.

iPhones and iPads also have relatively small amounts of RAM compared to Android devices in the same class, so I wonder if Apple is doing something smart with offloading memory to fast SSD storage in a way that isn't noticeable to the user.

Not on iOS.

This is most probably more linked to Java/Kotlin vs Objective-C/Swift. Want an array of 1000 objects in Java ? You'll endup with 1001 allocations and 1000 pointers.

Pretty sure you'll end up with exactly the same in an NSArray? ObjC is excellent but it's not doing anything fundamentally magic there

In Swift you can add value types to the heap-backed array directly, in ObjC you can use stack allocated arrays (since you have all of C) and there are optimizations such as NSNumber using tagged pointers.

Theoretically Java should be more memory efficient because it makes fewer guarantees and can move memory around.

The advantage of Swift/ARC is not that it uses less memory per se but that it has a lower high water mark because memory is freed much sooner.

> Theoretically Java should be more memory efficient because it makes fewer guarantees and can move memory around.

Java makes a lot of memory guarantees that are hard to make efficient. Specifically in that it becomes extremely hard to have a scoped allocation. Escape analysis helps, but the nature of Java's GC'd + no value types means it's basically never good at memory efficiency. Memory performance can be theoretically good, but efficiency not really. That's just part of the tradeoff it's making. And nearly everything is behind a reference, making everything far larger than it could be.

Compaction helps reduce fragmentation, but it comes at the cost of necessarily doubling the size of everything being compacted. Only temporarily, but those high-water spikes are what kicks things to swap, too.

Big difference is that Objective-C is a superset of C. Any Objective-C developer worth his/her salt will drop down to C code when you need to optimize. The object-oriented parts of Objective-C are way slower than Java. But the reason Objective-C programs can still outcompete Java programs is that you have the opportunity to pick hotspots and optimize the hell out of them using C code.

Object-oriented programs in Objective-C are written in a very different fashion from Java programs. Java programs tend to have very fine granularity on their objects. Objective-C programs tend to have interfaces which are bulkier, and larger objects.

That is partly why you can have a high performance 3D API like Metal written in a language such as Objective-C which has very slow method dispatch. It works because the granularity of the objects have been designed with that in mind.

For those, Apple's favored approach to memory management (mostly reference counting) absolutely _is_ an advantage over Android's (mostly GC). That's not relevant when comparing an Intel and ARM Mac, tho.

> but I have seen a bunch of reviews claiming that 8GB is perfectly fine.

Has anyone actually used one of these long enough to fairly compare with an x year old laptop in regular use?

Reply on news.ycombinator.com