Tracking developer build times to decide if the M3 MacBook is worth upgrading
Engineers share data from thousands of Go builds to decide whether upgrading MacBook Pros from M1 and M2 to M3 makes financial and productivity sense, finding that M2 is a big jump over M1 while M3 offers only modest gains on M2 but still justifies replacing older M1 machines. Commenters debate alternatives such as distributed or remote builds, cloud dev boxes, and desktops, and scrutinize the statistical methods and AI-assisted analysis used in the study. Many also weigh in with practical experience on Apple Silicon performance, RAM constraints, and the trade-offs between faster local feedback loops and more complex remote setups.
Upgrade value: M1 vs M2 vs M3
- Broad agreement that M1 is a solid baseline; M2 often feels ~20–60% faster than M1 for builds in this org’s Go monolith and in some other workloads.
- M3 Pro is seen as only modestly better than M2 (~10% in this data and some user benchmarks), but clearly better than M1.
- For many commenters, M2 → M3 is not worth upgrading; M1 → M3/M2 can be.
- Several people report M3 Max offering limited benefit over M3 Pro for typical build workloads; extra cores often underused.
- Some argue used or discounted M1 Pro/Max gives most of the value at far lower cost.
RAM, memory bandwidth, and workloads
- Extra RAM strongly helps linking and caching; multiple reports of 16 GB regularly paging under load.
- Memory bandwidth differences matter a lot for local LLMs and some heavy builds; M2 Ultra (800 GB/s) and Max parts (400 GB/s) are favored for that, while some M3 Pro/Max configs are seen as bandwidth‑“nerfed”.
- Debate over 8 GB Macs: workable for small/medium projects with care, but may hammer SSD and feel sluggish for serious dev.
Local vs remote / distributed builds
- Some teams say powerful local laptops plus fast local builds (<30s) are vastly better for productivity and debugging than remote or CI-only workflows.
- Others report success with remote dev boxes, Kubernetes-based dev clusters, or distributed builds (distcc/sccache/Incredibuild), especially for huge C++/monolith codebases.
- Cloud dev is criticized as costly, latency-prone, and operationally complex, though very large companies can make it work well.
- Local-only development of entire product stacks is praised as rare but highly effective.
Methodology, statistics, and telemetry
- Several commenters like the build telemetry idea (tracking build times, environment, battery vs AC, RAM, etc.) and using it to catch regressions and inform hardware buys.
- Statisticians and data‑savvy readers criticize:
- Potential cohort bias (newer hires with newer machines working on different kinds of changes).
- Use of t‑tests without modeling non‑independent samples; suggest mixed‑effects models or non-parametric tests.
- Heavy reliance on histograms; recommend boxplots or CDFs for clearer comparisons.
- Nonetheless, many see the exercise as “good enough” for internal decision‑making and valuable org learning.
AI‑assisted analysis
- The use of an OpenAI “assistant” to run Python/pandas over CSV data impresses many; seen as dramatically lowering the activation energy for this kind of analysis.
- Some remain skeptical about correctness and reproducibility, preferring explicit R/Python workflows, but note you can inspect the generated code or export notebooks.
Mac vs alternatives and dev experience
- Strong pro‑Apple‑Silicon sentiment: huge jump over Intel Macs for VS Code, compiles, and battery; Intel MBPs often described as “paperweights” by comparison.
- Some argue MacBooks are overpriced status symbols and that desktops or non‑Mac laptops plus remote compute are more cost‑effective.
- Others counter that, for laptops, MacBooks still dominate on performance per watt, thermals, noise, screen, speakers, and unplugged performance.
- Endpoint security/management agents on corporate laptops are reported to significantly degrade performance, independent of CPU generation.