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-03-01 15:50:44 -04:00
parent 57a0fa3a4a
commit 316a049e96
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 39 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_1_41749c4c9b317a58e02df99f748844a1._comment Normal file
View file

@ -0,0 +1,39 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-03-01T18:06:32Z"
content="""
Since you mentioned standalone builds, I suspect you are running
something like: "git-annex.linux/git-annex test"
I have verified that is much much slower than running git-annex not
from the standalone build.
It seems that every time the test suite runs git, it does it via runshell,
and repeated calls to runshell take time since it has to re-set up the
standalone environment. This does not happen when the test suite runs
git-annex; I've verified that its use of programPath results in
git-annex.linux/bin/git-annex being run, which avoids the runshell
overhead.
It looks like the problem is that PATH ends up
containing "git-annex.linux:git-annex.linux/bin", and so it runs
the runshell wrapped git. That happens due to setTestMode, which
appends the current directory to the PATH.
Now, I doubt there would be a real benefit to testing using the standalone
build, running ./git-annex in the tree where you built it, unless the
standalone build is made on a system other than the system where the test
is run.
But still this repeated runshell is excessive. And should be able to be
fixed easily now that I've understood it.
However: The main thing I know that will speed up git-annex test generally
is to parallelize its tests. Which can be done, but needs tasty-1.2. That
finally made it into debian stable, so it should be able to depend on it
now. I would not be surprised if it can be sped up 10x that way, because tests
often have to wait one or more seconds after writing a file due to time
stamp issues etc. I have created a `paralleltest` branch with a start on
that, not yet working.
"""]]