word "index" was used, I knew someone would suggest to design a daemon, a
stable and generic index format and an RPC interface (and maybe DBUS
support?), and that's like killing flies with a cannon. Just profile the
program! The bottleneck is not in loading the potential 10s of package
names that will match and checking their exported symbols, the bottleneck
is scanning all (potentially 1000s) directories inside GOPATH, checking all
filenames to see if they have a .go extension (potentially 10s of 1000s)
and loading all local packages just to check for their package name
declared in their .go files.
All that's needed is a simple cache which stores:
path-to-directory | has-go-files? | package-name-declared-in-go-files
And define what invalidates the cache (is the directory mtime, considering
its drawbacks, enough?).
That drops execution time from ~7s to ~0.1s (on a SSD). There's no doubt
that you can optimize it further with an index of the per-package exported
symbols, but that's not gonna give you more than a 0.1s gain, while a
simple cache gives you ~6.9s. Also, the moment you introduce a daemon there
are further issues to consider, which makes the solution way more
complicated that it needs to be (who's responsible for starting and
stopping this daemon? what if it gets stuck? etc...).
Please, keep this discussion about what it should be: making tools/imports
(and hence goimports) faster for the common usage scenarios without
introducing additional complexity for the end user. There's no need for
Google's scale solutions, indices nor daemons.
On Tuesday, April 28, 2015 at 5:54:26 PM UTC+1, Josh Bleecher Snyder wrote:
FWIW, goimports is slow for me too, although I
do have a very large GOPATH.
This is also a pain point for me. It is particularly ugly when I makeFWIW, goimports is slow for me too, although I
do have a very large GOPATH.
automated changes that span many, many files and then save them all.
This can take minutes.
I like the idea of an optional RPC call to an external service that
manages the cache.Agreed. The main advantage to this that I see is that there can be
many third-party external services e.g.:
* An fsevents-powered cache
* The editor, so that goimports could be aware of unsaved changes
There's a bit of careful designing to do. E.g. the RPC should probably
return all matching import paths, so that policy decisions that should
live in goimports (e.g. issue 10339) don't get farmed out.
If there are no objections to supporting this (Brad?), maybe we should
transfer discussion of design details to an issue.
-josh
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
