Or is there something else going on?
bun:test is fast mostly because it’s integrated deeply into the runtime. Other test runners typically have to mutate globals and spend a lot of time setting up the environment and tearing it down. Also, expect() in bun:test is something like 10x faster[1] than in vitest (100x jest) because it’s written in native code.
Test runners involve a lot of polymorphism which means JS doesn’t get JIT’d much — in cases like that, writing in native is much faster.
Another factor is transpilation time. bun:test supports TypeScript and JSX without plugins and bun’s transpiler is very fast
[1]: https://twitter.com/jarredsumner/status/1595681235606585346?...
1. JSC rather than V8
2. Built in APIs. A lot of nodes APIs are implemented in JS and for this reason (or simply because they’re not well optimised), they run more slowly than Bun’s implementation.
3. Bun also has a highly optimised built in test runner
JSC vs V8 is interesting... I'd like to see something like tsc compile times for real projects compared. And then again against something like SWC (rust impl) :) I doubt we'll switch to bun any time soon for prod runtime, but for speeding up tsc/lint/babel/etc, sure!
Anyway. Last I checked Bun still handily beats SWC (and ESBuild) on basically everything, and beats Node on tons (all?) of runtime metrics. Perf has been its foundational principle from the start, and every aspect of what’s under test in the article has been specifically mentioned as optimization targets by Bun’s creator. You’ll find many of your questions answered on his Twitter[1].
One thing I think is worth adding is that Bun’s perf obsession has been percolating a lot of optimizations upstream to WebKit/JSC. So even if you don’t ever adopt Bun as a server runtime, you or your users are likely benefiting from those contributions on the client.
1: https://twitter.com/jarredsumner?s=21&t=ZMU7ao_SpJj349QDow0M...
What did you check? Bun only has basic transpiring currently. I can't imagine what "everything" is, and without bundling, minification, and down-transpiling support I don't see how any meaningful project could have been tested on.
> Bun’s perf obsession has been percolating a lot of optimizations upstream to WebKit/JSC
Source? AFAIK claiming either "bun devs made a lot of JSC perf optimization PRs" or "bun devs pointed perf hot spots to JSC devs" would be incorrect, but I'd love to learn otherwise.
Yeah, build/bundling use cases have lagged in priority. I’ll rephrase “everything” as “every transpiling use case”.
> Source? AFAIK claiming either "bun devs made a lot of JSC perf optimization PRs" or "bun devs pointed perf hot spots to JSC devs" would be incorrect
Jarred’s Twitter has been frequently highlighting these contributions. This seems like a weird thing to object to if you’re so familiar with the project!
But the call time had gone north of 1 second so there was a lot of friction to adding more questions. I subsequently fixed some dumb bootstrapping code to the tune of ~250 ms, which would have been enough to add all of our current apps to the tool, but what really helped was using worker threads knowing the number of environments to check was finite. We only needed k threads so we could eat startup time entirely.
Bun is also faster. If you added my fix and used Bun, you could use forking to cover cases that are O(m) instead of O(k). (Typically k << m < n when doing orders).