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.
Eliminating JavaScript cold starts on AWS Lambda
21–30 of 72 posts
Re: Eliminating JavaScript cold starts on AWS Lambda
#22Re: Eliminating JavaScript cold starts on AWS Lambda
#23Awesome work, but I am genuinely curios about the use cases where the 200ms init time being a problem?
Re: Eliminating JavaScript cold starts on AWS Lambda
#24Tl;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.
But other than that it's impossible to assess performance with such a tiny toy.
Re: Eliminating JavaScript cold starts on AWS Lambda
#25It'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.
Re: Eliminating JavaScript cold starts on AWS Lambda
#26https://nodejs.org/api/single-executable-applications.html#s...
Re: Eliminating JavaScript cold starts on AWS Lambda
#27Awesome work, but I am genuinely curios about the use cases where the 200ms init time being a problem?
Re: Eliminating JavaScript cold starts on AWS Lambda
#28Awesome 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 ?
Re: Eliminating JavaScript cold starts on AWS Lambda
#29Re: Eliminating JavaScript cold starts on AWS Lambda
#30Earlier 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.
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.