`go env GOCACHE`
# sst
t
go env GOCACHE
f
Are you suggesting on code change, we rebuild all the Lambda handlers? Each handler takes ~0.2s to build. The handlers I was testing were dummy, not sure the time will be longer for real projects.
I found some code that runs concurrent go builds leveraging all CPU cores. Even that, if you have a handful of Lambdas, rebuilding all takes non-trivial time right?
t
yeah the thing is there's no way to influence what gets built. I could edit something in a shared package that effects another package which effects another package which effects lambda 1, 3 and 5
Since it gets built into a single binary you would have to rebuild all of them
Go already tries to optimize things when you ask it to "build everything" by caching some of the steps
f
Got it!
After building an executable
go build -o main main.go
, the first run
./main
takes 40ms, and subsequent runs take <10ms. Is that expected? And is there a way to “pre-warm” the executables?
t
Yeah I think that's building up the cache. Not sure if there's a way to do it other than to build it once