|
diff_cmd = ('git', 'diff', '--no-ext-diff') |
|
diff_before = cmd_output_b(*diff_cmd, retcode=None) |
|
if not hook.pass_filenames: |
|
filenames = () |
|
time_before = time.time() |
|
language = languages[hook.language] |
|
retcode, out = language.run_hook(hook, filenames, use_color) |
|
duration = round(time.time() - time_before, 2) or 0 |
|
diff_after = cmd_output_b(*diff_cmd, retcode=None) |
|
|
|
# if the hook makes changes, fail the commit |
Hi all,
I am looking at implemented pre-commit to replace a harder-to-maintain custom bash script our company current uses. In my initial tests, pre-commit works great, except for the fact that it is slow. The majority of our hooks are readonly in nature, and run quite fast. However, on our repository, pre-commit is spending close to 1 second per hook performing a before/after diff.
I added some instrumentation, and in our test case with 10 executed hooks, the execution time of pre-commit is >7 seconds with the before/after diffs, and ~1 second with those diffs disabled. I will note this is an extremely large repository, with many thousands of files. Generally, git actions are somewhat slow on it.
In exploring issues related to perf, I had found #510, which seems to tackle a different problem - individual hooks that take a while, rather than the overhead of pre-commit itself. However, there was one comment that got me thinking, regarding a readonly attribute one could apply to a hook. I know - this metadata would only be as truthy as the author who wrote the hook, but if a hook was marked as readonly, pre-commit could theoretically skip the before/after hook diffs.
Any thoughts? Happy to contribute the PR if maintainers see this as valuable.
pre-commit/pre_commit/commands/run.py
Lines 175 to 185 in 4f5cb99
Hi all,
I am looking at implemented pre-commit to replace a harder-to-maintain custom bash script our company current uses. In my initial tests, pre-commit works great, except for the fact that it is slow. The majority of our hooks are readonly in nature, and run quite fast. However, on our repository, pre-commit is spending close to 1 second per hook performing a before/after diff.
I added some instrumentation, and in our test case with 10 executed hooks, the execution time of pre-commit is >7 seconds with the before/after diffs, and ~1 second with those diffs disabled. I will note this is an extremely large repository, with many thousands of files. Generally, git actions are somewhat slow on it.
In exploring issues related to perf, I had found #510, which seems to tackle a different problem - individual hooks that take a while, rather than the overhead of pre-commit itself. However, there was one comment that got me thinking, regarding a
readonlyattribute one could apply to a hook. I know - this metadata would only be as truthy as the author who wrote the hook, but if a hook was marked as readonly,pre-commitcould theoretically skip the before/after hook diffs.Any thoughts? Happy to contribute the PR if maintainers see this as valuable.