[OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)
Alexander Kanavin
alex.kanavin at gmail.com
Tue Aug 13 13:20:36 UTC 2019
On Tue, 13 Aug 2019 at 11:04, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:
> We talked on irc and you pointed at the commit things started to go
> wrong. Just to summarise things for the benefit of the list, this is
> some quick testing I did:
>
> "bitbake -p; time bitbake core-image-minimal -n"
>
> 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> 40.3s 7df31ff36892c2f9c65326b06b4c70
> 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c
> 76.9s master-next
>
> So basically the original changes showed a 25% hit but the performance
> of -next is dire.
>
Sadly with larger sets the performance hit is much worse. I enabled all of
the layers in meta-oe, and ran this with empty sstate and build directories:
bitbake -p; time bitbake -n -k world
The outcomes are:
6c7c0cefd34067311144a1d4c01986fe0a4aef26
12m51,848s
(this is the baseline; the bulk of the time goes towards going through the
task list without executing the tasks - the 'spinning task counter" part)
9983b07fffd19082abded7c3f15cc77d306dd69c
66m29,563s
So there could be something quadratically-growing going on with these new
commits :(
I didn't dare to try master-next after seeing above how it hits
core-image-minimal and master already regressing to over an hour :-(
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190813/e834a148/attachment.html>
More information about the Openembedded-core
mailing list