On Tue, 13 Aug 2019 at 11:04, Richard Purdie <richard.purdie@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