Added a comment
authoryarikoptic <yarikoptic@web>
Tue, 8 Jun 2021 20:23:09 +0000 (20:23 +0000)
committeradmin <admin@branchable.com>
Tue, 8 Jun 2021 20:23:09 +0000 (20:23 +0000)
doc/bugs/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment [new file with mode: 0644]

diff --git a/doc/bugs/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment b/doc/bugs/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment
new file mode 100644 (file)
index 0000000..a8051f1
--- /dev/null
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 15"
+ date="2021-06-08T20:23:09Z"
+ content="""
+ok -- I think it (or at least a part of it, datalad test is still running) boils down to `git-annex add` now doing some `O(n-staged * n-cmdline-paths)` lookup/operation (instead of before just `O(n-cmdline-paths)`) whenever we have a series of `annex add --json cmdline-paths ...`. This is reflected by the fact that if before we had about `~30 sec` per each invocation of `annex add`, now we have `30 284 528 720`.
+
+In any case in datalad we should finally switch to use `annex add --batch`, filed [an issue](https://github.com/datalad/datalad/issues/5721), but I guess may be it could also be addressed on git-annex side since sounds like some suboptimal data structure is used for some paths' matching.
+"""]]