Very slow on windows mingw

[xoxloviwan]

test coverage run slow

MINGW64 /c/Projects/gopherkeep (user-info-2)
$ time go-test-coverage --config=./.testcoverage.yml
File coverage threshold (0%) satisfied:         PASS
Package coverage threshold (0%) satisfied:      PASS
Total coverage threshold (0%) satisfied:        PASS
Total test coverage: 33%

real    0m12.457s
user    0m0.015s
sys     0m0.060s

Why it may be?

file .testcoverage.yml

# (mandatory) 
# Path to coverprofile file (output of `go test -coverprofile` command).
#
# For cases where there are many coverage profiles, such as when running 
# unit tests and integration tests separately, you can combine all those
# profiles into one. In this case, the profile should have a comma-separated list 
# of profile files, e.g., 'cover_unit.out,cover_integration.out'.
profile: cover.out

# (optional; but recommended to set) 
# When specified reported file paths will not contain local prefix in the output
local-prefix: "github.com/xoxloviwan/memopass"

# Holds coverage thresholds percentages, values should be in range [0-100]
#threshold:
  # (optional; default 0) 
  # The minimum total coverage project should have
  #total: 20

[vladopajic]

hey

was this v2.11.2? that version has some performance improvement that speeds up execution time.

[xoxloviwan]

It was v2.10.1 (go 1.22)

[xoxloviwan]

was this v2.11.2? that version has some performance improvement that speeds up execution time

MINGW64 /c/Projects/gopherkeep (user-info-2)
$ time go-test-coverage --config=./.testcoverage.yml
Total test coverage: 42.9% (537/1252)

real    0m7.669s
user    0m0.045s
sys     0m0.046s

It is better, but not ideal... Thanks

[vladopajic]

i am not sure why on win it is this slow.
feel free to investigate and contribute with pr.

[xoxloviwan]

I didn't find build instructions in Makefile, can you describe that anywhere?

[vladopajic]

there is no need to build, you can just run using source, for example:

go run ./main.go --config=.testcoverage-local.yml

if you really need to build there is docker file, or just simply: go build .

[xoxloviwan]

It is weird, but all the time is wasted on runtime.cgocall

      flat  flat%   sum%        cum   cum%
     8.76s 33.77% 33.77%      8.76s 33.77%  runtime.cgocall
         0     0% 33.77%      8.76s 33.77%  github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage.Check
         0     0% 33.77%      8.76s 33.77%  github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage.GenerateCoverageStats
         0     0% 33.77%      8.76s 33.77%  github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage/coverage.GenerateCoverageStats
         0     0% 33.77%      8.76s 33.77%  github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage/coverage.GenerateCoverageStats.findFileCreator.func1
         0     0% 33.77%      8.76s 33.77%  go/build.(*Context).Import
         0     0% 33.77%      8.76s 33.77%  go/build.(*Context).importGo
         0     0% 33.77%      8.76s 33.77%  go/build.Import
         0     0% 33.77%      8.76s 33.77%  main.main
         0     0% 33.77%      8.63s 33.27%  os.(*Process).Wait (inline)

one trace fragment

Wall Duration | 177 893 612 ns
Self Time | 177 893 612 ns

runtime.syscall_syscalln:521
syscall.Syscall:457
syscall.WaitForSingleObject:1140
os.(*Process).wait:28
os.(*Process).Wait:358
os/exec.(*Cmd).Wait:906
os/exec.(*Cmd).Run:610
go/build.(*Context).importGo:1255
go/build.(*Context).Import:670
go/build.Import:1534
github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage/coverage.GenerateCoverageStats.findFileCreator.func1:43
github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage/coverage.GenerateCoverageStats:71
github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage.GenerateCoverageStats:69
github.com/vladopajic/go-test-coverage/v2/pkg/testcoverage.Check:15
main.main:190

[vladopajic]

it looks like build.Import in findFileCreator takes the most of the time. maybe build.Import(dir, ".", build.FindOnly) call can be optimized? maybe on windows it it searching in unnecessary places - that is maybe instead of using Default context we can use some other? maybe second argument srcDir of build.Import could be changed to something else?

[vladopajic]

additional note, unit tests for this repository are also running much slower on windows (~57sec) then on ubuntu (~5sec) and macos (~5sec) . here is unit tests action example.

probably it is because of same cause.

[vladopajic]

yes it's build.Import.

it's Impossibly slow really ,; my compile and test of my own app is quicker than running this coverage check - can't imagine what's going on to cause this. adds about 2 minutes to the build for a repo with like 20 files in it

is there an alternative algorithm or surely this call is causing issues in other projects or go itself?

if you are using win machine feel free to find different solution or real cause of issue.

as stated in #139 (comment):

1. maybe call of build.Import for windows can be changed, maybe second argument needs to be changed form . to something else? maybe this is causing issue?
2. maybe build.Import could be run on custom context. currently build.Import uses Default context which may cause this function to search unnecessary directories (something that unix versions are not searching).