Live data from Hacker News

Eliminating JavaScript cold starts on AWS Lambda

goose.icu

21–30 of 72 posts

Re: Eliminating JavaScript cold starts on AWS Lambda

#24

Tl;dr Use an experimental (as in, 60% of ECMA tests passing, "currently no good I/O or Node compat") AOT compiler for JS. You remove the cold start by removing the runtime, at the cost of maybe your JavaScript working and not having a garbage collector.

It might be reasonable to go without a garbage collector if your whole lifetime is so short. GC by decapitation. Kinda clever.

But other than that it's impossible to assess performance with such a tiny toy.

Re: Eliminating JavaScript cold starts on AWS Lambda

#25
post #15

It'd be good if AWS Lambda provided a wasm runtime option. Cold start times for WebAssembly can be sub-millisecond. It'd also be interesting to see comparisons to the Java and .NET runtimes on AWS Lambda.

Rust/C++ lambda cold starts are in the 15ms ballpark, it is very unlikely that you are going to get anything much faster than that. Spinning up firecracker vm just inherently takes some time no matter what you run inside it.

https://maxday.github.io/lambda-perf/

Re: Eliminating JavaScript cold starts on AWS Lambda

#26
I wonder if the author is aware of Node native features that improve startup times, like V8 code cache and startup snapshots. An overview of integrating them into native single-executable applications is here:

https://nodejs.org/api/single-executable-applications.html#s...

Re: Eliminating JavaScript cold starts on AWS Lambda

#28
post #23

Awesome work, but I am genuinely curios about the use cases where the 200ms init time being a problem?

Maybe its a problem when you’re paying 200ms per small request and you have millions of them ?

Some companies who actually depend on actions like this should consider fronting some cash to keep this project going.

Re: Eliminating JavaScript cold starts on AWS Lambda

#30
post #17

Earlier quoted context omitted.

I really find it annoying when JavaScript people complain about performance. If you think something is slow then make it faster and open a pull request. It’s great when those PRs do come, but most of the time there is just empty whining while a developer contributes nothing. This is because most JavaScript developers are deathly afraid to write original software, as that would be reinventing a wheel. Most JavaScript…

I'm not complaining about performance, I'm complaining that people say they put out something faster and smaller only to find out they're not remotely comparable. Did you know that moment.js used to be a microlibrary? It came out replacing "the huge Date.js library." If you've been in the field long enough, you've seen this cycle repeat over and over.

You were complaining about performance. If you, as in yourself the actual person, are not measuring things its just whining.

moment is a library discontinued years ago. They had a couple of commits in 2023 and a couple in 2022, but work stopped on the library almost 5 years ago. It is an abstraction over the big scary native Date object.

Up until 2 years ago I was writing JS full time for 15 years. I just saw a lot of people bitch and cry about inventing wheels and whining at performance targets they just guessed at. Its because most of these people could not write code. During this time there were some amazing things being written in JavaScript, and later TypeScript, but these awesome things were almost exclusively personal hobby projects the regular employed JS developer either bitched about or relied upon for career survival, because bitching and crying is what you do when you can't otherwise contribute in a meaningful way.

Post reply on HN