[PATCH] D114325: Add a best practice section on how to configure a fast builder

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

Generally seems like a good direction to go in, if it's feasible - but it seems like a pretty big step up in resource expectations than the past/current buildbots/workers, so I'm not sure how feasible it is to get those resources.



================
Comment at: llvm/docs/HowToAddABuilder.rst:154-155
+
+As mentioned above, we generally have a strong preference for
+builders which can build every commit as they come in.  This section
+includes best practices and some recommendations as to how to achieve
----------------
do we have any builders that achieve this consistently (I wouldn't think so, given the resources required)? Maybe worth rephrasing if it's  not actually achievable/achieved generally to something more in line with the practical reality?

If this document is more aspirational/trying to set a fairly new (albeit good, but perhaps not feasible?) direction - maybe it'd be more suitable in a different form/forum?


================
Comment at: llvm/docs/HowToAddABuilder.rst:212-216
+  Using ccache materially improves average build times.  Incremental builds
+  can be slightly faster, but introduce the risk of build corruption due to
+  e.g. state changes, etc...  At this point, the recommendation is not to
+  use incremental builds and instead use ccache as the latter captures the
+  majority of the benefit with less risk of false positives.
----------------
Seems like we should figure out how to make incremental builds more reliable - to benefit developers (& then have buildbots using incremental builds to ensure they do keep working so developers can benefit from them being reliable). But, yeah, if it's just not practical today, so be it.


================
Comment at: llvm/docs/HowToAddABuilder.rst:224-227
+  With multiple workers, it is tempting to try to configure a shared cache
+  between the workers.  Experience to date indicates this is difficult to
+  well, and that having local per-worker caches gets most of the benefit
+  anyways.  We don't currently recommend shared caches.
----------------
Is this about multiple workers on the same machine, or some kind of network shared cache? Presumably if we're suggesting people have multiple workers per builder (to get fast enough cycle time/short enough blame list) - that's multiple machines (since generally we could get enough parallelism to saturate a machine in the build - I guess not all the time, so maybe there's some parallelism benefit to multiple workers on the same machine?)


================
Comment at: llvm/docs/HowToAddABuilder.rst:236-238
+  As a last resort, you can configure your builder to batch build requests.
+  This makes the build failure notifications markedly less actionable, and
+  should only be done once all other reasonable measures have been taken.
----------------
That's the default/what most (all?) of the buildbots are doing today, though, yeah?


================
Comment at: llvm/docs/HowToAddABuilder.rst:198
+  generally provides a good balance between build times and bug detection for
+  most buildbots.
+
----------------
reames wrote:
> mehdi_amini wrote:
> > rengolin wrote:
> > > `RelWithDebugInfo` is perhaps even more helpful, because you test the optimisation pipeline, get smaller objects to link, and still, in case of stack traces, you can see from the logs directly where to begin looking.
> > RelWithDebugInfo seems a bit heavy to me: the objects gets ~10x larger IRRC.
> > If what you're about is better stack traces in case of crashes, then `-gmlt` (line tables only) gets it to you without blowing up the disk size / link time.
> I think I managed to address this with the revised wording, let me know if further tweaking is warranted.
Split DWARF can reduce linker input size/time too, for what that's worth - but maybe enough in the noise/weeds/details to be omitted here.


================
Comment at: llvm/docs/HowToAddABuilder.rst:211
+  use incremental builds and instead use ccache as the latter captures the
+  majority of the benefit with less risk of false positives.
+
----------------
rengolin wrote:
> This is true, however in the more limited targets (like our initial Cortex A9 targets back in the day), even ccache wasn't enough to speed up our builds, mostly because autoconf+make wasn't smart enough, IIRC.
> 
> It's possible that CMake+ninja plays well enough with ccache that makes incremental builds obsolete, but I have not done the proper testing to confirm that.
what smartness was lacking from autoconf+make that meant ccache was ineffective in this situation? (I thought the point of ccache was that it didn't matter how the build system worked, basically)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114325/new/

https://reviews.llvm.org/D114325