New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/cover: ParseProfiles is very slow on large coverage files #32211
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Performance
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Comments
Want to contribute your change? |
julieqiu
added
the
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
label
May 28, 2019
/cc @ianthehat |
Change https://golang.org/cl/179377 mentions this issue: |
gopherbot
added
the
Tools
This label describes issues relating to any tools in the x/tools repository.
label
Sep 12, 2019
gopherbot
pushed a commit
that referenced
this issue
Mar 14, 2021
After CL 179377, this change deletes all the prior cmd/cover code and instead vendors and type aliases code using the significantly optimized golang.org/x/tools/cover, which sped up ParseProfiles by manually parsing profiles instead of a regex. The speed up was: name old time/op new time/op delta ParseLine-12 2.43µs ± 2% 0.05µs ± 8% -97.98% (p=0.000 n=10+9) name old speed new speed delta ParseLine-12 42.5MB/s ± 2% 2103.2MB/s ± 7% +4853.14% (p=0.000 n=10+9) Fixes #32211. Change-Id: Ie4e8be7502f25eb95fae7a9d8334fc97b045d53f Reviewed-on: https://go-review.googlesource.com/c/go/+/249759 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Trust: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Go Bot <gobot@golang.org>
Change https://golang.org/cl/325909 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jun 8, 2021
Updates #32211 Change-Id: Ie38e831fcf557534023afd552d9394fe9e055caa Reviewed-on: https://go-review.googlesource.com/c/go/+/325909 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Performance
Tools
This label describes issues relating to any tools in the x/tools repository.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I'm using a tool that uses
golang.org/x/tools/cover
to parse the coverage files output bybazel coverage
on kubernetes/kubernetes. The resulting (perhaps somewhat pathological) output has 3 GB of output across 827 files, totalling about 36 million blocks.What did you expect to see?
Reasonably fast parsing of the coverage files.
What did you see instead?
The tool spends 72 seconds inside
cover.ParseProfile
, and 61 of those seconds are spent inParseProfile
's calls toregexp.FindStringSubmatch
.Going down the rabbit hole while I was waiting, a relatively simple (but less readable) regexp-less implementation instead spent 11 seconds in
cover.ParseProfile
, of which 2 seconds were spent in the replacement for the regexp.The text was updated successfully, but these errors were encountered: