何时使用 Xcode 分布式构建功能
我在一个小型 iPhone 开发团队工作，在我们的办公室里，我们在任何时候至少有 4 个 XCode 副本在网络上运行。考虑让每个人都运行它。
我们使用标准 WIFI 交换机联网，因此网络速度和延迟不如有线网络...
只是想知道，使用分布式构建是否有任何实时增益？一旦它通过网络来回传递相关数据。至少对于相对较小的项目来说是这样。
I work in a small iPhone development team, in our office, we have at least 4 copies of XCode running on the network at any one time. Contemplating getting everyone to have it running.
We're networked together using a standard WIFI Switch, so network speed and latency isn't as good as wired network...
Just wondering, is there any real time gain to be had on using distributed builds? Once it passes the relevant data back and forth over the network. At least for relatively small projects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于您的项目、其依赖项以及必须传输的数据量。
15-20秒并不可怕。当然，总体而言还有更多工作要做。对于每个人来说，将其分配给一台非常快的 Mac Pro 可能是一个好主意，而不是如果您使用双核（未提供该信息），则不要互相分配。
至于项目配置：如果您的项目中有一堆依赖库，那么禁用预编译头可能会有所帮助。等式的大部分是依赖项的平均数量以及要生成的对象的数量。
15-20 秒，这将帮助许多开发人员进行编写，以便他们在外包之前优化构建时间。如果是几分钟，那么您可能想直接跳到具有 8 或 12 核的分布式构建。
小项目缓慢构建的一个容易被忽视的方面是：禁用每个构建的静态分析，然后每隔两小时手动运行一次，然后修复每个问题。
否则，您的项目可能会被分成更小的项目/库。很可能，您不会总是编辑相同的依赖项。
假设编译、链接等是此时花费时间的地方：其余大部分都属于构建 C 和 C++ 程序所涉及的典型问题。尽量减少依赖并包含图表。实际上用 objc 很容易完成；由于许多接口都使用 objc 类型，因此您可以使用转发。
如果您的库很小（例如生成的对象少于 50 个），那么您也可以通过不使用预编译头来获得加速。如果一切已经取决于您包含的 12 个系统框架包含在 pch.... 中，那么请在下一个项目中尝试。
当然，您可以尝试计时一次干净的重建、使用生成的 pch 文件进行构建以及几次增量构建，以便得出结论。
it depends on your project, its dependencies, and the amount of data that must be transferred.
15-20 seconds is not terrible. certainly, there is more work overall to be done. it may be a good idea for everyone to farm it out to a very fast Mac Pro, rather than to each other if you're using dual cores (that info was not given).
as far as project configuration: if you have a bunch of dependent libraries in your projects, then it may help to disable precompiled headers. much of the equation is the average number of dependencies, and the number of objects to generate.
at 15-20 seconds, it would help many developers to write so they optimize their build times before farming out. if it were a few minutes, then you may want to jump straight into distributed builds with a 8 or 12 core.
one easily overlooked aspect of slow builds on small projects: disable static analysis per build, and just run it manually every hour two, fixing every issue then.
otherwise, your project could probably be divided into smaller projects/libraries. chances are, you won't always be editing the same dependencies.
assuming compilation, linking, etc are where the time is spent at this point: much of the rest falls into the typical issues involved with building c and c++ programs. minimize your dependencies and include graphs. it's actually quite easy to accomplish with objc; since much of the interfaces use objc-types, you can use forwards.
if your library is small (e.g. less than 50 objects generated), then you may also gain a speedup by not using precompiled headers. if everything already depends on your inclusion of 12 system frameworks included by the pch.... then try it in the next project.
of course, you could just try timing a clean rebuild, a build with generated pch files, and several incremental builds in order to come to a conclusion.