Their Node runtime (based on 8.x) is now the fastest, but I note that Node 12 includes the version of v8 that supports snapshots. Node 12 goes LTE next month and from what I understand, once snapshots could give Node another significant start-up speed boost.
Forgive me if I'm wrong, but I believe it's because Node is implemented with V8 which is a JIT compiler rather than just an interpreter, not to mention that Node is a more mature and optimized runtime than the Go toolchain.
My assumption here is that the Node implementation loads your code off disk during cold start using standard require(). Whereas the Go implementation requires loading a small wrapper (probably also in Node) which execs the Go process which then handles your request.
In my experience, GCP Functions Go cold start time is almost nil because they compile your code into the function entry point directly, so it's as quick as calling a function in process.
OK, so the main takeaway for me for example would be that if I want write lambdas in Go (because it's awesome), then GCP would be better choice for me.
But anyway, I'm not too current when it comes to lambdas. Are they compiled everytime when cold started, or is a compiled binary stored in some sort of image?
They are compiled during the deploy process, with the binary or code + deps (for JS etc) stored on S3 and loaded on demand. This counts as part of the cold boot time.
11 comments
[ 2.0 ms ] story [ 36.8 ms ] threadIn my experience, GCP Functions Go cold start time is almost nil because they compile your code into the function entry point directly, so it's as quick as calling a function in process.
But anyway, I'm not too current when it comes to lambdas. Are they compiled everytime when cold started, or is a compiled binary stored in some sort of image?
I wish there was some more info about the testing methodology...