From 8bb86ee97e5284bde69161afeb451cde6f10fc66 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 19 Apr 2022 14:04:14 -0400 Subject: [PATCH] comment --- ..._5027255cc1b0dec41e315df8472fe60e._comment | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment new file mode 100644 index 0000000000..541fbd34d7 --- /dev/null +++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment @@ -0,0 +1,29 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 9""" + date="2022-04-19T16:42:16Z" + content=""" +Well, maxextensionlength does at least have some connection to the +filename, which does point at it being somewhat suitable for +gitattributes. Eg, you might want to allow files with one long extension +to include it all, but not others. + +The current implementation uses a single git check-attr process which +reports on all 4 currently supported git-annex attributes for every query. +So adding a new attribute also slows down queries for all the rest by some +amount. To quantify that, I did a benchmark, modifiying git-annex to +request (but ignore) an additional attribute. git-annex add of 10000 +small files did not slow down by any measurable amount due to that change. +(1:53.78 before the change and 1:52.00 afterwards actually, so the +difference is lost in the noise) + +An attribute does impose more overhead than git-annex +config though, since it has to be queried for every file rather than one +time. I benchmarked the overhead of checking annex.maxextensionlength +once per file added, over 10000 files. It slowed down by around 5%. + +git-annex add already queries the annex.largefiles attribute once per file. +So, if it could also query annex.maxextensionlength at the same time, +it would be free to support the attribute. And then I'd certianly be in +favor of it. This would need some nontrivial refactoring of the code. +"""]]