"Searching for modified files..." phase is slow, CPU bound and single core

[VorpalBlade]

The phase "Searching for modified files..." is really slow (over a minute and a half for me on an AMD Ryzene 5600X with NVME storage) and it appears to be single core and CPU bound (not IO bound). This is quite a long and annoying cycle time.

It would be nice if it could be sped up using for example GNU Parallel (a bit like xargs but much improved). I had a look at the code, and I believe it should be possible to run with GNU Parallel using exported bash functions. The function would need to output to stdout how to update the global state (found_files, orig_file_props, etc). Since GNU Parallel (unlike xargs) can be invoked to prevent parallel output clobbering each other this would be fine.

I could make a PR for this, but I don't know your policy on adding new dependencies, and it would be a fair bit of work for something that might get rejected out of hand.

[MenacingPerson]

aconfmgr save --skip-checksums works

[CyberShadow]

I had a look at the code, and I believe it should be possible to run with GNU Parallel using exported bash functions.

The program which would need to be parallelized is paccheck. I don't know how you would achieve this with exported bash functions.

Unless paccheck is emitting a lot of output in your case?

[VorpalBlade]

Hm, I misread the code. I thought it ran paccheck per package for some reason. My bad. Writing a parallel replacement to paccheck might be something I take a look at down the line though.

EDIT: It might be possible to switch to running paccheck per package (or batches of packages) though, which would allow it to run in parallel.