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):
>
> jnml@r550:~/src/github.com/cznic/browse$ go install -tags
> debug.browse && browse
> 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
>
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.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
