alandefreitas
commented
1 year ago When I applied clang-unformat to a code base consisting of 158 C++ files with 51k LOC, it took more than 10 hours on a Core i7 laptop to generate the configuration file, and on an Apple M1 Max it still took 3 h 41 min to complete (both with 8 threads in parallel).
Wow :open_mouth:
One of the reasons I wrote this small application is because the alternative I could find was an equivalent python script that was taking me many days to generate the configuration file.
The same project took me 30 minutes with clang-unformat and then 8 minutes with 4 threads.
I've never seen anything like 3h 41min but it's not hard to imagine a situation where this would happen.
Profiling revealed that most of the time is spent calculating the Levenshtein distances.
Yes. That's supposed to happen.
That's actually a good thing because it's a bottleneck that's easy to optimize.
If most of the time were spent on I/O then we would have a more serious problem.
This patch replaces the original algorithm by a call to the corresponding function in Edlib (https://github.com/Martinsos/edlib).
That's nice. How long does it take you now? Is it the same algorithm? Any conflicts with the license?
I guess other heuristics are also possible in large projects. In general, a reasonably large subset of the project should be enough to infer a valid configuration file.
Marzelpan
When I applied clang-unformat to a code base consisting of 158 C++ files with 51k LOC, it took more than 10 hours on a Core i7 laptop to generate the configuration file, and on an Apple M1 Max it still took 3 h 41 min to complete (both with 8 threads in parallel). Profiling revealed that most of the time is spent calculating the Levenshtein distances. This patch replaces the original algorithm by a call to the corresponding function in Edlib (https://github.com/Martinsos/edlib).
On the Core i7 the patched version of clang-unformat with
--parallel 8takes 21m:41s to complete, and on the M1 the runtime is reduced to 4m:26s.