3 ms·

It's a huge bottleneck for iOS/MacOS devs. I work on a fairly large app. Clean builds are 45 minutes on my 2019 Intel i7, and incrementals can be 5 - 10 min (wh

It's a huge bottleneck for iOS/MacOS devs. I work on a fairly large app. Clean builds are 45 minutes on my 2019 Intel i7, and incrementals can be 5 - 10 min (which is still insane to test small changes). The M1 guys are seeing 33% - 50% reductions in build time. We have a lot of tooling that only exists to try to stay productive while running builds. Anything to speed up the build times is instant productivity gained.

rixed 5y ago
Weren't compile farms a thing decades ago? What happened to them?
- bagacrap 5y ago
  that works if your machines are on the same network but less well if you are WFH
- fingerlocks 5y ago
  We do this. But with 25 devs making dozens of builds of a day each, plus daily develop branch builds, PR builds, RC builds, et al., the queue is backed up. And attaching lldb to an iOS device with debug symbols means copying the 500mb build output back to your local machine. Really only useful when your multi-tasking back and forth between a couple of different bugs/features.
  - rixed 5y ago
    Oftentimes build farms that I've came across were implemented by leveraging the local dev machines so it would naturally scale with number of devs. Copying back the debug build is indeed more of an issue as it depends on network gears that rarely scale linearly with headcount. Yet I would expect network transfers to take only a fraction of the build time, if those 500mb of output are associated with the 10mins builds referred to in the OP, possibly even in a WFH environment these days. I'd rather believe that build farms work better in a more homogeneous environment and require more work to maintain, whereas every individual dev can manage his own machine, especially in our post-distro world (old grumpy man wanted to add: I remember a time when I was a new hire in a company and my manager asked me to attach my desktop to the build farm; I must have had a face like "Huho, sounds complicated" so he added: "I mean, just apt-get install distcc")

rixed 5y ago

Weren't compile farms a thing decades ago? What happened to them?

bagacrap 5y ago
that works if your machines are on the same network but less well if you are WFH
fingerlocks 5y ago
We do this. But with 25 devs making dozens of builds of a day each, plus daily develop branch builds, PR builds, RC builds, et al., the queue is backed up. And attaching lldb to an iOS device with debug symbols means copying the 500mb build output back to your local machine. Really only useful when your multi-tasking back and forth between a couple of different bugs/features.
- rixed 5y ago
  Oftentimes build farms that I've came across were implemented by leveraging the local dev machines so it would naturally scale with number of devs. Copying back the debug build is indeed more of an issue as it depends on network gears that rarely scale linearly with headcount. Yet I would expect network transfers to take only a fraction of the build time, if those 500mb of output are associated with the 10mins builds referred to in the OP, possibly even in a WFH environment these days. I'd rather believe that build farms work better in a more homogeneous environment and require more work to maintain, whereas every individual dev can manage his own machine, especially in our post-distro world (old grumpy man wanted to add: I remember a time when I was a new hire in a company and my manager asked me to attach my desktop to the build farm; I must have had a face like "Huho, sounds complicated" so he added: "I mean, just apt-get install distcc")