Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eliminating JavaScript cold starts on AWS Lambda

goose.icu

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Eliminating JavaScript cold starts on AWS Lambda

#11

Post by unfunco »

I really don't struggle that much with cold starts on Node.js/Lambda, and I don't do anything special, my build commands look like:

    esbuild src/handler.ts --bundle --external:@aws-lambda-powertools --external:@aws-sdk --minify --outfile=dist/handler.js --platform=node --sourcemap --target=es2022 --tree-shaking=true
Maybe I'm not doing as much as others in my functions and I tend to stick within the AWS ecosystem, so I save some space and I presume cold-start time by not including the AWS SDK/Powertools in the output, but my functions tend to cold start and complete in ~100ms.

Re: Eliminating JavaScript cold starts on AWS Lambda

#13

Post by samwillis »

Oliver is doing awesome work here. A few interesting points:

- Porffor can use typescript types to significantly improve the compilation. It's in many ways more exciting as a TS compiler.

- There's no GC yet, and likely will be a while before it gets any. But you can get very far with no GC, particularly if you are doing something like serving web requests. You can fork a process per request and throw it away each time reclaiming all memory, or have a very simple arena allocator that works at the request level. It would be incredibly performant and not have the overhead of a full GC implementation.

- many of the restrictions that people associate with JS are due to VMs being designed to run untrusted code. If you compile your trusted TS/JS to native you can do many new things, such as use traditional threads, fork, and have proper low level memory access. Separating the concept of TS/JS from the runtime is long overdue.

- using WASM as the IR (intermediate representation) is inspired. It is unlikely that many people would run something compiled with Porffor in a WASM runtime, but the portability it brings is very compelling.

This experiment from Oliver doesn't show that Porffor is ready for production, but it does validate that he is on the right track, and that the ideas he is exploring are correct. That's the imports take away. Give it 12 months and exciting things will be happing.

Re: Eliminating JavaScript cold starts on AWS Lambda

#14

Post by eliseumds »

bapak wrote: post #4

I seriously dislike this kind of comparisons. We're faster! (please disregard the fact that we're barely more than a demo) Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does. Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill…

Idk, I'm having a good experience with Biome 2 in a large codebase. 4s to do a full-check including floating promises, undeclared and cyclic dependencies, and sorting imports. Our ESLint setup used to take almost a minute. The Biome team has been fixing bugs on a daily basis. Version 2.2.0 (released 3 days) ago addressed a common high-CPU-usage bug, try it out.

Edit: it's not 4s anymore, I just measured with the latest version and it takes ~900ms. Insane.

Re: Eliminating JavaScript cold starts on AWS Lambda

#16

Post by bapak »

eliseumds wrote: post #14
bapak wrote: post #4

I seriously dislike this kind of comparisons. We're faster! (please disregard the fact that we're barely more than a demo) Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does. Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill…

Idk, I'm having a good experience with Biome 2 in a large codebase. 4s to do a full-check including floating promises, undeclared and cyclic dependencies, and sorting imports. Our ESLint setup used to take almost a minute. The Biome team has been fixing bugs on a daily basis. Version 2.2.0 (released 3 days) ago addressed a common high-CPU-usage bug, try it out. Edit: it's not 4s anymore, I just measured with the late…

I did try and it just stalls, taking down my CPU with it. I had moved onto other tasks and found it later still killing a few cores. It's in a monorepo with maybe 3000 files. I have no trust in the project.

Re: Eliminating JavaScript cold starts on AWS Lambda

#17

Post by bapak »

austin-cheney wrote: post #7
bapak wrote: post #4

I seriously dislike this kind of comparisons. We're faster! (please disregard the fact that we're barely more than a demo) Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does. Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill…

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.

Re: Eliminating JavaScript cold starts on AWS Lambda

#18

Post by eliseumds »

bapak wrote: post #16
eliseumds wrote: post #14

Earlier quoted context omitted.

Idk, I'm having a good experience with Biome 2 in a large codebase. 4s to do a full-check including floating promises, undeclared and cyclic dependencies, and sorting imports. Our ESLint setup used to take almost a minute. The Biome team has been fixing bugs on a daily basis. Version 2.2.0 (released 3 days) ago addressed a common high-CPU-usage bug, try it out. Edit: it's not 4s anymore, I just measured with the late…

I did try and it just stalls, taking down my CPU with it. I had moved onto other tasks and found it later still killing a few cores. It's in a monorepo with maybe 3000 files. I have no trust in the project.

Yeah I understand the frustration, I had issues setting up ESLint/Prettier years ago and spent a few hours getting the Biome configuration right. Also a monorepo with ~4000 TS/TSX files. If you ever feel like trying it again, make sure that you have "files.maxSize" and "files.ignoreUnknown" set. And be very careful with the "files.includes" list.

Re: Eliminating JavaScript cold starts on AWS Lambda

#19

Post by syrusakbary »

breve wrote: 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.

If you want to run in a WebAssembly runtime, perhaps Wasmer can be a good choice for you.

Note: we don't support .NET or Java atm, but we support PHP and Python is about to be fully supported!

https://wasmer.io/products/edge

Re: Eliminating JavaScript cold starts on AWS Lambda

#20

Post by hylaride »

breve wrote: 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.

Java startup times would almost certainly be worse, depending on what's going on.

A previous job I worked at ran Java on AWS Lambda. We ran our busiest Java lambda in a docker layer as our whole build system was designed around docker and from a compute performance point of view it was just as fast.

The main issues were:

* Longer init times for the JRE (including before the JIT kicks in). Our metrics had a noticeable performance hit that lined up to the startup of freshly initialized lambdas. It was still well within a tolerable range for us, though.

* Garbage collection almost never ran cleanly due the code suspension between invocations, which means we had to allocate more memory than we really needed.

The native AWS Lambda Java's 'snap start' would have helped, but the startup times were just not a big deal for our use case - we didn't bother with provisioning lambdas either. Despite the added memory costs, it was also still cheap enough that it was not really worth us investigating Java's parallel GC.

So as always, what language one should use depends on your use case. If you have an app that's sensitive to "random" delays, then you probably want something with less startup overhead.

Post reply on HN