XcodeBenchmark
XcodeBenchmark measures Mac performance in Xcode by compiling a relatively large codebase.
The project has already saved thousands of dollars for developers and companies when they purchase or upgrade their Macs and I believe these results will help you make the right cost/performance choice.
The code is primary C-family languages, but it also includes some Swift.
Of note:
- No one submitted iMac scores. With the 27-inch and Pro models gone, and the MacBook Pro much improved, I don’t hear much about iMacs being used for development anymore.
- The 16-core M4 Max is faster than the 24-core M2 Ultra.
- There’s a much bigger difference between the 10-core M4 and the 12-core M4 Pro than between the 12- and 14-core M4 Pros.
When going from M4 to 12-core M4 Pro, we are adding p-cores and removing e-cores and thus the increase to score per core is justified. When going from the 12-core M4 Pro to any higher-tier chip, we are again adding p-cores but the score per core decreases, indicating diminishing returns (you would expect the score per core to increase because the e-core / p-core ratio is changing in favor of p-cores).
Previously:
- Xcode 16.2
- MacBook Pro 2024
- Apple M4 Pro and M4 Max
- Mac mini 2024
- iMac 2024
- M1 Ultra Mac Studio Compilation Benchmarks
- Apple M1 Benchmarks
- Developer Transition Kit Benchmarks
- Subversion Compilation Benchmarks
7 Comments RSS · Twitter · Mastodon
Is it because they are rewriting more and more of Xcode in Swift? Unit tests seem to take forever to run now..
maybe i’m just noticing more since I’ve been writing a lot of tests lately but it seems like shit has gotten awfully slow
@ObjC4Life I’m not sure what’s going on, but I find that unit tests run much faster (and don’t mysteriously end with a crashed process) if I set the scheme not to connect to the debugger.
Thanks for the tip. I'll have to give that a try and see if it helps. I'm not sure though since the problem for me seems to be more about the build time.
It seems if I make any small change to the source code between unit test runs it may be building everything from scratch or triggers some code path in the compiler that is really slow. Maybe switching the scheme to the main app briefly in between runs also is required to reproduce (which is something I do often).
By "switching the scheme" I really meant running the main app briefly in between unit test runs.
Seems to be the thing. If I run unit tests, they finish, then run the main app, building the main app is very slow.
If I run the main app, stop it, then run unit tests building is very slow.
Modifying the source code doesn't even seem to be required.
@ObjC4Life Yeah, I think I’ve seen that when I had my main app compiled using the Debug configuration and my tests compiled using the Test configuration, but both using the same scheme. You would think it would keep the intermediate build results separate (since there seem to be separate folders), but switching Build vs. Test would sometimes make it start from scratch. So I would use the Test config for the app, too, and then it would reuse the intermediate results.
Besides the slow build times I just noticed Xcode is regularly taking up over 20 GB of ram. I'm not even building anything right now. Just left a project window open. My Mac only has 16 GB of Ram so it's swapping.
Not sure if this is a "new thing" but it seems like a new one to me. I ended up stumbling across this because one of my apps uses a few NSCache objects. With Xcode feasting on my system's memory the caches were evicting objects immediately after they were inserted and I was thrashing (which was my bad) because after loading the objects I put in the cache in the background I called a delegate method on the main thread, which queried the cache but the object was already evicted. So on the bright side, Xcode's decline helped me find a bug I probably would have never discovered otherwise because no other app I use pigs out on memory like that.
