On Wed, 28 Feb 2024 at 16:41, Philip Lorenz <[email protected]> wrote: > > I'm assuming this data wouldn't be that large or that expensive to > > compute so I'd prefer not to hide it behind extra configuration options > > if we can help it. That does depend on the overheads/costs though. > > > I just executed build ID extraction on the debug packages of our medium > sized kirkstone based distro (see my reply to Alex for more details). > Sequentially extracting build IDs from around 8000 files took around > 1:30 minutes on my machine. While I wouldn't call this excessive, I am > also not sure whether this is too much overhead given that I only expect > this data to be used in some deployments.
I have to object to the numbers because they were done with a sequential shell loop. Debuginfod does it in threads and is able to complete the scans much faster. So you need to check how quickly it completes its job when started with oe-debuginfod rather. There might be an improvement coming from what you are proposing, but it's most likely not going to be as drastic. >From debuginfod manpage: -c NUM --concurrency=NUM Set the concurrency limit for the scanning queue threads, which work together to process archives & files located by the traversal thread. This important for controlling CPU-intensive operations like parsing an ELF file and especially decompressing archives. The default is the number of processors on the system; the minimum is 1. https://manpages.debian.org/testing/debuginfod/debuginfod.8.en.html There's also something else I noticed just now: there seems to be an alternative implementation of debuginfod you want to introduce? Why? If the original from elfutils isn't working well enough, shouldn't we make it better? One possibility is teaching it to mass-import pre-computed entries into its index, so that sweeping file tree scans with archive extractions can be avoided altogether. Or doing incremental index imports directly from do_package. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196398): https://lists.openembedded.org/g/openembedded-core/message/196398 Mute This Topic: https://lists.openembedded.org/mt/104619206/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
