You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For large numbers of comby operations on large source bases, it can take upwards of an hour to process all the files in my testing. This comes down dramatically (5mins!) if I parallelise my calls to comby with multiprocessing up to 32 ways. Unfortunately comby has a default 3 second timeout, and complicated files / very busy periods means that some files trip the timeout and don't get processed.
I've added the ability to set the comby timeout in my local branch and it now gives me correct results with the performance improvements.
Attaching the diff I used here as part of the feature request in case it's something interesting for the main project. comby-timestamps.diff.txt
The text was updated successfully, but these errors were encountered:
For large numbers of comby operations on large source bases, it can take upwards of an hour to process all the files in my testing. This comes down dramatically (5mins!) if I parallelise my calls to comby with multiprocessing up to 32 ways. Unfortunately comby has a default 3 second timeout, and complicated files / very busy periods means that some files trip the timeout and don't get processed.
I've added the ability to set the comby timeout in my local branch and it now gives me correct results with the performance improvements.
Attaching the diff I used here as part of the feature request in case it's something interesting for the main project.
comby-timestamps.diff.txt
The text was updated successfully, but these errors were encountered: