[oe] RFC: SRC_URI_OVERIDES_PACKAGE_ARCH

Richard Purdie rpurdie at rpsys.net
Sat Aug 11 14:23:45 UTC 2007


On Sat, 2007-08-11 at 15:11 +0200, Koen Kooi wrote:
> Richard Purdie schreef:
> > The problem is that translating SRC_URI to localpaths is computationally
> > expensive. In the SRCREV case, it involves hitting the network which is
> > very slow. If we use the localpath calls at all, we hit the database
> > which will slow down parsing.
> > 
> > We have several options:
> >  * restore the old behaviour, accept the parsing slowdown
> 
> If people want to know how much the slowdown is, add:
> 
> SRC_URI_OVERIDES_PACKAGE_ARCH = "1"
> 
> to your local.conf. On a dual opteron with U320 scsi disks it becomes unbearably slow.
> 
> I think checking only file:// paths is the best intermediate solution.

With bitbake 1.8.7 and SRC_URI_OVERIDES_PACKAGE_ARCH just set in recipes
that need it parsing OE.dev takes:

real    5m49.043s
user    4m35.649s
sys     0m11.057s

Whereas if we check file:// urls:

real    9m8.550s
user    5m55.542s
sys     0m45.847s

Its possible that machine was more loaded when I ran the second test but
it was reproducibly taking 9 mins vs 5.5 mins with just that change. Its
safe to say there is a 20%+ speed hit, probably worse.

For comparison bitbake 1.8.6 with SRC_URI_OVERIDES_PACKAGE_ARCH just set
in recipes that need it:

real    6m56.088s
user    4m50.558s
sys     0m11.933s

Whereas if we check file:// urls:

real    6m45.358s
user    4m52.466s
sys     0m12.225s

So we have what looks like a speedup in 1.8.7 if we can sort the
SRC_URI_OVERIDES_PACKAGE_ARCH problem...

I suspect I should throw away the sql based primary cache and go back to
the ugly global variable as its tons faster...

Cheers,

Richard





More information about the Openembedded-devel mailing list