Máté Na.gy

AboutBlog

Benchmarking the AMD Ryzen 9 9950X3D for js workloads

Before getting the latest and greatest that desktop CPUs have to offer in 2025, I wanted to check some benchmarks that showed if it made sense for my JavaScript dev workflow.

To my surprise there were no benchmarks for JavaScript, so I decided to do a quick one after getting it

The test

I had 2 easy to measure workflows in mind that I’d test with:

These were easy to measure, run a great deal of javascript code with high variety. Importantly they also represent the typical workflows I use with a lot of module importing and complex code-bases.

I ran the playwright tests manually 2 times and made sure to run it at times when the server load was low so it wouldn’t affect the results too much. For the Jest tests I’ve hyperfine to get a more accurate result.

Having access to these 2 large proprietary test suites put me in a unique position in being able to benchmark a very diverse and large codebase more typical of large companies.

The tests were done with Node v22.14.0 on Windows 10 I also made sure that the caches were populated before running the test and always taking the second result.

The baseline

The baseline setup before was a Ryzen 9 7950X3D with 64GB@6000Mhz CL30

The initial results were:

First result

After updating the BIOS and swapping the CPU, the results I got were very disappointing.

I was very surprised, but chucked it up to the new CPU maybe not being optimized for in Node or V8. This was a net slowdown of a couple of percent, which is not something I’d normally like to pay extra for, but I was beyond that point here sadly

Remembering to turn on memory overclocking

About one week after the upgrade while complaining about the CPU not being faster to a colleague, I had a realization. The BIOS update (which was needed, so my existing motherboard could support the new CPU) reset my BIOS settings, including the memory timings. This meant that the good DDR5 kit I had was running at default speed. I quickly restarted, this time remembering to enable EXPO, and re-ran the tests.

Jest results

The new results for the Jest unit tests were 137.311 s ± 1.805 s => A 9% improvement!

This was a decent improvement, which while not very cost-efficient, might be worth it, especially if it can speed things up by enough, so that I can stay in the flow.

Playwright results

The new results for Playwright were 19m52s - 169 passed => ~3% slower

Digging into the individual results, the timings are all over the place. Some tests were faster, and some were slower. There was no clear pattern either. From this I concluded that the E2E tests’ performance isn’t driven by CPU performance, hence why we don’t see an improvement.

Conclusion

The tests have demonstrated what I had already expected: Some workflows in js development are CPU bound and will get a minor speed-bump, while some other workflows are network-bound or IO-bound, and won’t see an improvement.

At the end of the day if you’re CPU-bound you can expect a ~9% performance bump from the previous best CPU, the 7950X3D

Whether that’s worth it is up for you to decide though. For me it was worth it, because every second less I have to wait increases the likelihood that I stay focused on what I’m doing and stay in the flow, which is currently the biggest limiting factor to my productivity