cmd/compile: takes too much cpu and fails when compiling huge go files

I use this go-embed tool for embedding resources into my executable directly. It produces a file like this https://github.com/pyros2097/go-embed/blob/master/examples/assets/main_prod.go.

But When I use this to build my frontend images which approximates to 20MB into a single main.go file which is also 20MB but is 300K+ lines of code It takes forever to compile and then crashes my CPU. I guess this is a problem because I have only 4GB of memory and an core i3 processor.
But it seems to compile properly on my friends 16GB laptop core i7.

Is there anyway I can make it compile on my laptop? Maybe by splitting the single file into many files or something?

My GoENV and go version go1.5.2 linux/amd64

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/pyros2097/Code"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Well I solved this in my tool,

previously the file structure was like this

package assets

// ImagesDocTXT file
var ImagesDocTXT = []byte{
    0x1f, 0x8b, 0x08, 0x00, 0x00, 0x09, 0x6e, 0x88, 0x02, 0xff, 0x0a, 0x49,
    0x2d, 0x2e, 0xc9, 0xcc, 0x4b, 0x57, 0x30, 0x54, 0x30, 0x52, 0x30, 0xe6,
    0x02, 0x04, 0x00, 0x00, 0xff, 0xff, 0x23, 0xc2, 0x19, 0x35, 0x0e, 0x00,
    0x00, 0x00,
}

And so I thought the lexer has to read a lot of tokens for upto 300K loc and that might be clogging it up so I then rewrote all the data to this

package assets

// ImagesDocTXT file
var ImagesDocTXT = []byte("\x1f\x8b\x08\x00\x00\x09\x6e\x88\x02\xff\x0a\x49\x2d\x2e\xc9\xcc\x4b\x57\x30\x54\x30\x52\x30\xe6\x02\x04\x00\x00\xff\xff\x23\xc2\x19\x35\x0e\x00\x00\x00")

And now the no of lines drop to about 50 and everything works fine.
Well I guess its about how you generate large code bases and mostly dealing with code generators and not the go compiler.
Closing this one for now

[bradfitz]

I'm reopening this. Even if you worked around it, the issue remains.

[extemporalgenome]

iirc, there's a very old issue relating to very large slice literals causing the compiler to use lots of memory and slow down. What that ever fixed?

[ALTree]

If you're referring to #11612 no, it's not fixed yet. It's in the 1.7 milestone.

[extemporalgenome]

@ALTree much older (known from at least around the 1.0-1.1 days). I'll try to dig it up. I suspect these are all the same issue though, and that fixing one will fix them all.

[dominikh]

@extemporalgenome #6643 and d227d68

[extemporalgenome]

@dominikh that's the one, thanks!