CL 179377 introduced an optimized parser for coverage profiles.
The parser replaces the following regex:
^(.+):([0-9]+)\.([0-9]+),([0-9]+)\.([0-9]+) ([0-9]+) ([0-9]+)$
With this regex, negative numbers in the coverage profiles resulted
in parsing errors. With the new parser in place, this is no longer
the case. This commit restores the old behavior.
Change-Id: Iaa72035f1f587ed186eaf5a84b209df88e67fb57
GitHub-Last-Rev: 07470fba9d587e6d3f383409fc8cf52bb882a984
GitHub-Pull-Request: golang/tools#195
Reviewed-on: https://go-review.googlesource.com/c/tools/+/213357
Reviewed-by: Katharine Berry <ktbry@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ParseProfiles currently uses a regex to parse each line. This is not
very fast, and can lead to ParseProfiles being excessively slow on
certain pathological inputs.
This change substantially improves the performance by parsing manually
instead. On an input of about 3 GB of data containing about 36 million
lines, the time spent in ParseProfiles drops from 72 seconds to 11
seconds, with actual string parsing time dropping from 61 seconds to 2
seconds.
Since this change completely changes the parsing, it also adds some
tests for ParseProfiles to help ensure the new parsing is correct.
A benchmark for parseLine is also included. Here is a comparison of the old
regex implementation versus the new manual one:
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)
Fixesgolang/go#32211
Change-Id: If8f91ecbda776c08243de4e423de4eea55f0082b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/179377
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change is ported from src/cmd/cover/profile.go[1].
Now that go test supported -coverprofile with multiple packages (#6909),
x/tools/cover/profile should also handle multiple samples from the same
location.
[1]: f39050c8ebFixesgolang/go#23076
Change-Id: I1b1d664bf56f7e22c6cb2726df44fb577408c6f7
Reviewed-on: https://go-review.googlesource.com/83078
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The error message is attempting to display the line of text, but was
incorrectly using m (which is always nil) instead of line.
Change-Id: Id09f488b3b7b0e8c3c2cb6e8f0a8d635861c77ac
Reviewed-on: https://go-review.googlesource.com/19330
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When cover is used with cgo packages, the coverage profile is produced
from the cgo-generated Go source files, so the profile will reference
line and column numbers from that generated source, even though it names
the original file.
This is okay in general because the cgo-generated Go source files are
very similar to the original, with one significant exception:
the original source may refer to C identifiers such as C.foo(), but the
cgo tool generates source that rewrites these mentions to something like
_Cfunc_foo.
This means that column numbers in coverage profiles might be higher than
they should be, so be lenient when interpreting them.
Update golang/go#9479
Change-Id: Ic3abef07471614101ce0c686d35b85e7e5e6a777
Reviewed-on: https://go-review.googlesource.com/2410
Reviewed-by: Rob Pike <r@golang.org>
Split the profile parsing code out of cmd/cover into
a reusable package, to support third-party coverage
tools.
R=golang-dev, r, adg
CC=golang-dev
https://golang.org/cl/36050045
