[ANN] browse
251 views
Skip to first unread message
Jan Mercl
Dec 15, 2016, 8:08:07 PM12/15/16
to golang-nuts
--
-j
Dave Cheney
Dec 15, 2016, 8:16:35 PM12/15/16
to golang-nuts
This is really impressive!
Adrian Lanzafame
Dec 16, 2016, 12:47:13 AM12/16/16
to Dave Cheney, golang-nuts
Awesome project!
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Seb Binet
Dec 16, 2016, 4:39:05 AM12/16/16
to Jan Mercl, golang-nuts
it looks really slick (and I like how one can quickly navigate between identifiers and go to their definition)
but I am curious: why the need for internal/gc, "a Go compiler front end. Work in progess" ?
it seems to be very much alike to go/types (or, rather, a mix of go/types and go/ast).
-s
PS: it's always very interesting to read your (Go) prose, thanks!
Jan Mercl
Dec 16, 2016, 6:22:47 AM12/16/16
to Seb Binet, golang-nuts
On Fri, Dec 16, 2016 at 10:38 AM Seb Binet <seb....@gmail.com> wrote:
> it looks really slick (and I like how one can quickly navigate between identifiers and go to their definition)
FTR, ctrl-click and middle-click open the target in a new window, like web bowsers do.
> but I am curious: why the need for internal/gc, "a Go compiler front end. Work in progess" ?
> it seems to be very much alike to go/types (or, rather, a mix of go/types and go/ast).
For example (not completely fair comparison but you get the idea):
main.go:162: loaded+xref0: 65 packages in 486.248926ms
jnml@r550:~/src/github.com/cznic/browse$ time ssadump .
real 0m2.218s
user 0m6.588s
sys 0m0.628s
jnml@r550:~/src/github.com/cznic/browse$
--
-j
adon...@google.com
Dec 16, 2016, 10:27:21 AM12/16/16
to golang-nuts, seb....@gmail.com
On Friday, 16 December 2016 06:22:47 UTC-5, Jan Mercl wrote:
> but I am curious: why the need for internal/gc, "a Go compiler front end. Work in progess" ?> it seems to be very much alike to go/types (or, rather, a mix of go/types and go/ast).
For example (not completely fair comparison but you get the idea):main.go:162: loaded+xref0: 65 packages in 486.248926msjnml@r550:~/src/github.com/cznic/browse$ time ssadump .real 0m2.218suser 0m6.588ssys 0m0.628s
ssadump is loading, cgo-preprocessing, parsing, and type-checking the entire transitive closure of source files required by the current package, then building its SSA representation in a second pass, so these measurements are not at all comparable. Two other data points:
1) If you modify ssadump to skip cgo preprocessing, type-checking of imported function bodies, and SSA construction:
conf.TypeChecker.FakeImportC = true
conf.TypeCheckFuncBodies = func(path string) bool {
return path == "github.com/cznic/browse"
}
... = conf.Load(...)
return
then it loads that package and its dependencies from source in under 700ms.
2) The golang.org/x/tools/cmd/gotype tool, which loads only a single package from source, and loads export data for all imports, can process that package in under 100ms.
The go/parser is plenty fast enough. ssadump may be the wrong starting point for how to use it, though.
Jan Mercl
Dec 16, 2016, 11:02:23 AM12/16/16
to adon...@google.com, golang-nuts, seb....@gmail.com
On Fri, Dec 16, 2016 at 4:27 PM adonovan via golang-nuts <golan...@googlegroups.com> wrote:
> ssadump is loading, cgo-preprocessing, parsing, and type-checking the entire transitive closure of source files required by the current package, then building its SSA representation in a second pass, so these measurements are not at all comparable.
I did not meant any unfair comparison, I just trusted what you wrote earlier in a different thread ;-)
----
> For example, with no flags, ssadump simply type-checks the specified packages:
>
> $ go get golang.org/x/tools/cmd/ssadump
> $ cat a.go
> package main
> var x int = "string"
> $ ssadump a.go
> a.go:2:13: cannot convert "string" (untyped string constant) to int
That's why I used it as a base line
----
> Two other data points:
> ...
> ...
> then it loads that package and its dependencies from source in under 700ms.
Nice.
> 2) The golang.org/x/tools/cmd/gotype tool, which loads only a single package from source, and loads export data for all imports, can process that package in under 100ms.
I wanted to be independent of .a files. I agree with what you have mentioned in the other thread - they are non reliable to be up to date.
> The go/parser is plenty fast enough. ssadump may be the wrong starting point for how to use it, though.
go/{scanner,parser} speed is okay. It's problem is that it does not scale well in parallel execution when there's a shared token.FileSet. That's the reason for internal/ftoken (locks on .File(), but the the returned *File methods do no more locking whatsoever):
jnml@r550:~/src/github.com/cznic/browse/internal/gc$ go version
go version go1.7.4 linux/amd64
jnml@r550:~/src/github.com/cznic/browse/internal/gc$ go test -bench .
BenchmarkScanner/StdGo-4 10 173466122 ns/op 41.53 MB/s
BenchmarkScanner/Std-4 30 37032476 ns/op 194.52 MB/s
BenchmarkParser/StdGo-4 5 275074432 ns/op 26.19 MB/s
BenchmarkParser/Std-4 10 138686331 ns/op 51.94 MB/s
PASS
jnml@r550:~/src/github.com/cznic/browse/internal/gc$
Again, the comparison is not completely fair, go/{scanner/parser} does more than this internal stuff is doing. At least as of now.
--
-j
Alan Donovan
Dec 16, 2016, 11:29:53 AM12/16/16
to Jan Mercl, golang-nuts, Sebastien Binet
On 16 December 2016 at 11:01, Jan Mercl <0xj...@gmail.com> wrote:
go/{scanner,parser} speed is okay. It's problem is that it does not scale well in parallel execution when there's a shared token.FileSet.
That's a good point. I measured the benefit of fine-grained locking and it's compelling; see https://github.com/golang/go/issues/1834.
Alan Donovan
Dec 16, 2016, 11:30:28 AM12/16/16
to Jan Mercl, golang-nuts, Sebastien Binet
Correction: https://github.com/golang/go/issues/18348
Reply all
Reply to author
Forward
0 new messages