rizsotto
citnames works for 8 to 10 minutes at the end of a build
Describe the bug
I found at the end of a build for a somewhat large project, that all compiling and linking tasks were complete, but bear still had a citnames process burning a full single core worth of CPU for 8 to 10 minutes before the build finally completed.
To Reproduce
Probably a little difficult since I can't give you access to the source.
Expected behavior
This process takes so long, without any feedback that users will think the build is permanently stuck. They may not be able to identify that bear is causing this.
This is likely similar to https://github.com/rizsotto/Bear/issues/486 (they didn't wait long enough?)
I understand that this may be normal and due to the amount of processing that needs to occur, it may be adequate to print some progress feedback and ETA.
Environment:
- OS name: Debian bullseye
- OS version: 11
- OS architecture: arm64 cross compiler in an x86_64 environment
- Bear version: 3.0.8
- Bear install method: package
Additional context
timo 2651108 0.0 0.0 6580 4192 ? S 14:41 0:00 \_ bear --append --output clientarm64.mak.compile_commands.json -- make -f clientarm64.mak -j12 all-targets
timo 2947683 99.2 0.9 326492 315636 ? R 15:05 7:35 \_ /usr/bin/citnames --input clientarm64.mak.compile_commands.sqlite3 --output clientarm64.mak.compile_commands.json --run-checks --append
Hey @TTimo , thanks for the report.
Yes, the event collection and processing is not parallel. It happens after the build. And if the build executes a lot of commands, then the event file gets big, processing takes more time.
Unfortunately I can't recommend a workaround. The new version I am working on is processing the events as they happen, so won't have this delay between the build finish and the output file ready.
Even if you can't share the project source. I would be interested about some metrics. Could you look how much entry the event file has and how much time it takes on your machine to process those?
