[Buildroot] [RFC v3 00/30] Add per-package staging feature

Fabio Porcedda fabio.porcedda at gmail.com
Wed Mar 11 17:29:35 UTC 2015

On Tue, Mar 3, 2015 at 3:21 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Fabio Porcedda,
> On Tue, 3 Mar 2015 15:03:46 +0100, Fabio Porcedda wrote:
>> > Could you give some hints about the performance impact of those copies
>> > of the staging directory? Does it continue to make the top-level
>> > parallel build thing useful?
>> IMHO the per-package staging feature is useful even without taking in
>> consideration the top-level parallel build, the unspecified optional
>> dependency issue are not common, they can generate build faulres or
>> just binary with unexpected behavior.
> Yes, correct, this is indeed another benefit of this approach.
>> > Preferably something with a fairly deep dependency tree, i.e lots of
>> > small packages that depend on each other. A X.org stack + gtk2 would be
>> > a good example.
>> The most complete selection of package that i've tested is the
>> defconfig + allyespacakgeconfig (693 targets), i've tried to enable a
>> wider range of packages, defconfig + glibc + allyespackageconfig but
>> even without using the pps they fail to build.
>> So i will provide build times of the configuration defconfig +
>> allyespackageconfig.
> Ok.
>> If you provide a defconfig on the release 2015.02, i can try to build that.
> Something like:
> BR2_arm=y

I've used a system with: i5-3470 (4 core @ 3.2GHz); RAM: 8GB; SSD.
Using you defconfig:

normal:                 20m
with parallel:          13m
with parallel & pps: 15m

Using a defconfig + allyespacakgeconfig:
normal:   85m
parallel:  40m
pps:       42m

I've repeated the test few times and taken the minimum value, but i
was still using the system so maybe the real values can change a bit.

I was surprised that the pps doesn't affect too much the build times,
but probably the ssd helps a lot.

Fabio Porcedda

More information about the buildroot mailing list