I'd guess people might be curious on the actual parsing/cache impacts of this series.
To be honest I'm having trouble isolating a parsing time change for it, which is quite sad. Someone with a slower system or limiting it to a small set of cores might get some better results. I can see slight reductions in the generate_dependencies function times. I was also profiling the "bitbake -S" cache mode, better results might be obtained without enabling that. It does reduce the overall "bitbake -S none" cache file size by around 420k (on a 74MB file). Much more significantly, it also reduces the do_package sigdata file from 224k to 159k uncompressed or 54k -> 36k compressed (which the files are). Whilst those improvements don't sound much, this is a significant reduction in the amount of data bitbake is chucking around pipes internally and the reduction in size of the sigdata will mount up over many recipes/tasks in an sstate share. I do think we can end up with cleaner more understandable/maintainable code if we do this correctly so whilst I had hoped for more, I still think this direction is the right one and the changes are worth pursuing. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175500): https://lists.openembedded.org/g/openembedded-core/message/175500 Mute This Topic: https://lists.openembedded.org/mt/96052504/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
