41–50 of 60 posts
Can someone tell me why there isn't almost any laptop with Linux and ARM? Is it more efficient than x86 though
Chromebooks are essentially this, but not that great for local development.
Earlier quoted context omitted.
if imports are slow one should probably look into pre-compiling .pyc files into the Lambda bundle
This is a well known issue, and the fix is not to create any boto3 clients at runtime. Instead, ensure they're created globally (even if you throw them away) as the work then gets done once during the init period. The init period gets additional CPU allocation, so this is essentially "free" CPU. Source: I'm a former AWS employee.
https://aws.amazon.com/blogs/compute/aws-lambda-standardizes...
Can someone tell me why there isn't almost any laptop with Linux and ARM? Is it more efficient than x86 though
It’s interesting that the author chose to use SHA256 hashing for the CPU intensive workload. Given they run on hardware acceleration using AES NI, I wonder how generally applicable it is. Still interesting either way though, especially since there were reports of earlier Graviton (pre v3) instances having mediocre AES NI performance.
[0]: https://neosmart.net/blog/will-amds-ryzen-finally-bring-sha-...
- How is Rust only one order of magnitude faster than Python?
- How is Python that much faster than Node.js?
So I looked at the benchmark repo.
These benchmarks mean nothing folks!
Each of these benchmarks is just a SHA256 hash. This is NOT a valid way to compare CPUs, except if the only thing you will ever do with the CPU is to execute SHA256 hashes.
Hash functions are not representative of the performance of:
- Compression or decompression (of text, video, or anything really)
- Parsing
- Business logic (which is often dominated by pointer chasing)
So, you can safely ignore the claims of this post. They mean nothing.
I found that Node 22 had ~50ms slower coldstarts than Node 20. This is because the AWS Javascript V3 SDK loads the http request library which became much heavier in Node 22. This happens on the newly released Node 24 as well.
I recommend that if you are trying to benchmark coldstarts on Lambda, you measure latency from a client as well. The Init Duration in the logs doesn't include things like decrypting environment variables which adds ~20ms and other overhead like pulling the function code from S3. The impact of this manifests when comparing runtimes like llrt to Node, the Init Duration is faster than Node, but the E2E time from the client is actually closer because the llrt bundle size is 4-5MB larger than Node.
Amazon was so ridiculously gimped and expensive that it was almost unfair, thus comparing ARM and X64 on Amazon thus runs into whatever arbitrary "savings" AWS does.
What I don't get is why is it that Node is dog slow . Seriously it seems borderline unusable. In terms of perf, Node has a pretty snappy JIT, and seems to perform OK in the browser, but this seems like something's not right here. ~200ms requests even in the light case are on the very brink of barely acceptable. On the other hand, Python performs very well, but it's alarming to see it gets slower in every release by a…
Earlier quoted context omitted.
This is a well known issue, and the fix is not to create any boto3 clients at runtime. Instead, ensure they're created globally (even if you throw them away) as the work then gets done once during the init period. The init period gets additional CPU allocation, so this is essentially "free" CPU. Source: I'm a former AWS employee.
Thanks for citing your sources, I think your source may be out if date, though! The “free init time hack” was killed in August (unless I’m missing something - never used it myself). https://aws.amazon.com/blogs/compute/aws-lambda-standardizes...
SnapStart is more widely available, which is the other option for shrinking the billed time spent in init (when I left, only Java SnapStart was available)
I would not be surprised that Rust be faster than Python, but looking at the code of his Benchmarks, I'm not sure that it really means anything. For example, the "light" test will do calls to "dynamodb". Maybe you benchmark python, or you benchmark the aws sdk implementation with different versions of python, or just you benchmark average dynamodb latencies at different times of the day, ... And, at least for Python,…
I think the 'light' workload is the most realistic - most people use lambda as a stateless CRUD backend/REST endpoint, I don't think doing heavy number crunching is that idiomatic inside a lambda. And for that use case, Python seems almost as good as Rust, which is surprising to me, as is the fact that Node runs so slow - I have a ton of Node-based lambdas in prod, and while they're no speed demons, I'm quite surpris…