mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2022-04-19 14:04:14 -04:00
parent 17b20a2450
commit 8bb86ee97e
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 29 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment Normal file
View file

@ -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.
"""]]