First open of a `.go`file extremely slow

[caarlos0]

Prerequisites

• [x] Have you tried launching atom . from the terminal in your project's directory?
• [x] Have you verified the output from go env is correct? If it is, please include the output in this issue.
• [x] Have you updated Atom to the latest version?
• [x] Have you tried using Atom Beta, which can be run side-by-side with Atom Stable? Is the behavior the same, or different?
• [x] Have you updated your Atom packages to the latest versions?
• [x] Have you read the FAQ?
• [x] Have you searched the issues to see if others are experiencing the same issue?

Description

If I open a Go project, and then open any .go file, it takes ~5secs for it to open. With the go-plus plugin disabled, it takes <1sec.

After opening the first file, others seems to load in normal speed.

Output from atom -v && apm -v

Atom    : 1.16.0
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0
apm  1.16.1
npm  3.10.5
node 6.9.5 x64
python 2.7.13
git 2.12.2

Output From go env

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/carlos/Code/Go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.8.1/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.8.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9x/tv3x0jcj1w9g94dbsy7nvqfr0000gn/T/go-build500752406=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

Steps to Reproduce

1. cd to a go project
2. atom .
3. open any .go file

Expected Behavior

File opens fast.

Actual Behavior

File takes ~5secs to load.

[joefitzgerald]

This is because we defer activation of go-plus until your first use of a go-plus command, or your first open of a go file. I will see if there's something obvious here because we do actually do most activation behind a debounce so you shouldn't be seeing this kind of delay.