Re: [BuildStream] Switching to buildbox-run for local builds
- From: Jürg Billeter <j bitron ch>
- To: Chandan Singh <chandan chandansingh net>
- Cc: buildstream-list gnome org
- Subject: Re: [BuildStream] Switching to buildbox-run for local builds
- Date: Mon, 27 Apr 2020 22:41:55 +0200
Hi Chandan,
On Mon, 2020-04-27 at 20:58 +0100, Chandan Singh wrote:
Hi Jürg,
Thanks for the write up, and more importantly for your efforts towards
making buildbox-run work nicely.
Definitely +1 from my side.
One question comes to mind - have you observed any differences in
performance using the buildbox backend compared to the bwrap one?
In my test builds of freedesktop-sdk I've noticed virtually no
difference in build time (144 min with bwrap vs. 142 min with buildbox-
run-bubblewrap+fuse). However, that build time is obviously dominated
by actual build commands. I haven't done any microbenchmarks of the
BuildStream/BuildBox overhead yet.
The difference may vary depending on the project. E.g., staging and
integration commands are much faster with buildbox-fuse (no hardlinking
and buildbox-fuse is much more efficient than pyfuse) while filesystem
access by build commands is slightly slower with buildbox-fuse (context
switch for not yet cached directory entries).
I haven't benchmarked BuildStream with buildbox-run with hardlinking
(i.e., without buildbox-fuse) yet. My focus has been on buildbox-run-
bubblewrap+fuse as that's the direct replacement of the current bwrap
(+pyfuse) backend, which is also Linux-only.
I expect the overall performance with buildbox-fuse to improve with
future optimizations, e.g., it should be relatively easy to optimize
output capturing.
I'd be in favor of keeping the bwrap backend around for a little
while. This is mostly to allow for a smoother fallback in case there
are any issues, and for performance comparisons. I understand that one
could fall back to an older version, but it'll be slightly nicer to be
able to compare master branches in both cases. This is not a big issue
but given that it doesn't cost us much to keep it for a while, I'd be
in favor of that.
Time-wise, maybe we can give it a month or so?
Sure, we can keep it around for a bit. I will also add a CI job to keep
testing bwrap until we remove the code, of course.
Cheers,
Jürg
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]