Created attachment 3609 [details] bitbake_memres_vs_nonres.log STATUS: FAILED BUILD: 2,3_M2 : 62d7d4130202d8ede16abf9e7d779361ca70847e ENVIRONMENT: Fedora 24 x86_64 STEPS TO REPRODUCE: 1) get poky sources (1.5 +) NOTE: The poky source should not have an already-made 'build' directory within 2) in a fresh shell session, source oe-init-build-env-memres 3) make any desired changes in local.conf 4) issue 'bitbake -n core-image-minimal' -- see expected results -- 5)change MACHINE to another acrhitecture in local.conf 6) issue 'bitbake -n core-image-minimal' -- see expected results -- 7) close the bitbake server by issuing command: 'bitbake -m' NOTE: Don't reuse this shell session for any further tests. Close it and continue testing in a new one. EXPECTED OUTCOME: Compare time spent for cache loading by bitbake between steps 4) and 6) . During step 6) it should be much shorter. ACTUAL OUTCOME: There's not significant difference between the first and the second executions. After running the script, it goes to immediately start parsing the recipes and then preparing and executing the tasks. There doesn’t seem to be any cache loading at any time either with the first or second machine setup. I also tested by first running oe-init-build-env instead of the resident version and the behavior was pretty similar: with no significant difference, except than on the non-resident version the execution was even faster by 1 or 2 seconds. I have attached a log with 4 timed executions exemplifying the case.
I tested again with 2.3_M2 rc3 (226a508da955439b881b2f0a544a3aee76e59919) and the behavior is still the same.
This behavior is reproducible on 2.2.1 rc1 (6a1f33cc40bfac33cf030fe41e1a8efd1e5fad6f), so it's necessary to back-port the fix once it's completed.
Created attachment 3668 [details] cache reload test log
The behavior is still reproducible on 2.3 M3 rc1.
I believe the test case was incorrect, I've changed the test case to correctly document how to test the cache reload overhead.