Why deno.exec is much larger than bun.exec
Deno executable is around 135mb in GNU/Linux whereas Bun's is much smaller, why is that, in fact when we look at the features both of them support, we can see that Bun is featureful too and when we look at the LoC (Lines of Code) for each project we will see this:
70 Replies
So basically the functionality is implemented with low level languages for each project, which are Rust for Deno and Zig/C/C++ for Bun. We clearly see that Deno has less LoC but still way larger exec.
Which can be caused by crates (rusty term. libraries) that used by Deno, and the underline engine that they are using which is V8 vs JavaScriptCore.
And at the same time Bun is faster than Deno? not just Bun's benchmarks (which they exaggerated) but other non-party benchmarks too, Deno seems slow, why? how can Deno improve itself, I really like Deno and how it approaches to the ecosystem, and trying to improve it slowly but in the way they think about the direction. Whereas Bun tries to do marketing with featureful thing which is NOT a good thing IMO.
But how can Deno really improve itself? Support for Node is given, V8 bindings are stabilized and everything but still in some benchmarks it can be slower than Node itself?
https://web-frameworks-benchmark.netlify.app/result?f=hono-deno,hono-bun,hono,express,express-deno,express-bun
https://www.youtube.com/watch?v=yJmyYosyDDM
Anton Putra
YouTube
Deno vs. Node.js vs Bun: Performance Comparison
🔴 To support my channel, I'd like to offer Mentorship/On-the-Job Support/Consulting (me@antonputra.com)
🍿 Benchmarks: https://youtube.com/playlist?list=PLiMWaCMwGJXmcDLvMQeORJ-j_jayKaLVn&si=p-UOaVM_6_SFx52H
👋 AWS is expensive - Infra Support Fund: https://buymeacoffee.com/antonputra
▬▬▬▬▬ Experience & Location 💼 ▬▬▬▬▬
► I’m a Senior Software...
As you can see it's even slower than Node when using Express and Hono frameworks.
Plz don't do microbenchmarks, those just tend show false results
Yes, I understand your point, but please look at the things I wrote too!
As I said in #general , rust binaries are gonna be bigger by default, you can change that, but there isn't a reason to
In the own video you linked, bun was faster, but not as reliable. Deno sems to favor reliability and security first
First of all yes, but Deno actually builds for Size and performance lmao.
GitHub
deno/Cargo.toml at b59c21d2c2e5035741bc443ea6649702218fc266 · denol...
A modern runtime for JavaScript and TypeScript. Contribute to denoland/deno development by creating an account on GitHub.
And deno by itself does more than bun (managing both jsr and npm, for example), bun doesn't do that
As you can see Deno enables; LTO, builds for Size...
yes, but create a zig project and rust project, make them both build optimizing for size, the rust build is still gonna be bigger
Bun supports JSR too.
Yes it's because Rust doesn't support LIBC...
not really, you need the jsr cli, which deno already has
you're free to provide a libc crate with the bindings, it's oss
https://docs.rs/libc/latest/libc/ like that.
libc - Rust
libc - Raw FFI bindings to platforms’ system libraries
then build with no std and just use libc
Sure, it can, then why not?
but no one does that, you're not gaining much
You can just look at the source code of both and check what bun doesn't do and what deno does, btw, that should cover the diff too
I haven't read much of the bun's source
Having half of the Code in Rust, having less feature but being 44M bigger, yeah it's because of Rust vs Zig, V8 vs JSCore and the functionality that those projects provide (which Bun thinks it has more feature)
deno has more features though, like more security and jsr
Security wise, I agree, but how much code JSR require?
I guess this is the file that imports everything essential to JSR: https://github.com/denoland/deno/blob/main/cli/jsr.rs
GitHub
deno/cli/jsr.rs at main · denoland/deno
A modern runtime for JavaScript and TypeScript. Contribute to denoland/deno development by creating an account on GitHub.
also that. widnows normally has bigger builds too, so you probably have some other problems
versions for reference
like what? I'm one Arch Linux (GNU/Linux x86_64)
But I was in 2.1.4, let me update it to 2.1.7
also dunno if linux symlinks the cache folder to inside the deno folder, that would also change stuff
It reduced by 2M, lol. Let me re-install with deleting
.deno directory.btw, stuff that bun doesn't provide on a normal install: lsp (deno lsp), formatter, the whole jsr stuff, permissions/security and probably more I forgot (I was just reading the folders)
Same, 137M, 2.1.7
that's just weird, lol
Yes, it's true that it doesn't provide LSP and FMT, security flags and JSR. But still I don't think those features increase the size of the exec by 40M.
if a win build is smaller than the linux one, the linux build is probably problematic
- some guy on the internet (forgot the name)
It is, I just fresh installed it with:
curl -fsSL https://deno.land/install.sh | sh
TBH Bun's WIN build is problematic too, if u look at it... on Linux it's 95M.ye, there's something really wrong with your installs, lol
nono, that's normal
actually yeah nvm, it's just 7M, btw I think there is no problem with Linux builds of Deno.
because your screenshot shows that there is 3M difference between 2.1.4 and 2.1.7
when I upgrade I reduced the binary by 2M too.
maybe it's not just optimized for linux? we need someone on mac to test, lol
like, it's a "problem" within the crates that deno uses?
I'm on CachyOS, I can install the executable provided by my distro? let's see!
you can probably try to build from source and see the size to test that and then try to locate the problem from the /target folder
hmm, so it's 38.08MiB when installing that means it's 7MiB less than Deno's official binary when installing with script.
let's see in binary size how much it will be.
I'm using scoop on windows, btw (basically brew, but "better")
CachyOS's own optimized binary.
we are actively working on reducing binary size and have some ideas and experiments to cut size drastically
any idea on why the win bundle is smaller? it should be the opposite
Yeah, I'm trying to brainstorm the idea and actually give an honest opinion to the creators by users.
no idea, windows is always a mystery to me :P
I think it's the opposite.
When I first started to start to learn Rust, the release builds on WIN was smaller.
we recently spotted something weird with out CI that produces 15mb larger binaries on linux than it does locally; not sure if that ended up being "something" or not.
https://www.reddit.com/r/rust/comments/wd0y2y/why_is_rust_binaries_on_windows_so_much_smaller/ ig that was already a thing?
Reddit
From the rust community on Reddit: Why is Rust binaries on Windows ...
Explore this post and more from the rust community
but even on that thread people got very different results
Hmm, I installed it with CachyOS repo too and it's 125M whereas Deno's official binary is 137M (so 12M difference, but it could be because CachyOS optimizes it for Zen 4 arch.)
arch user that didn't say that they use arch btw, are you really an arch user?
lemme do a clean build here too, src
ye,it's 102mb, ye
lol nah idc, I wish I could use gentoo
gh release is 107mb, wat
something is weird and I'm too dumb for this
I really think there is a problem.
How does a single-file executable compare for each? Since those don't include things like the LSP?
Informal test, on Windows, I created a Hello World single-file executable with both Bun and Deno
Deno's executable is way smaller, 70% the size of Bun's
to be honest I did not expect such a big difference
Bun
Single-file executable – Runtime | Bun Docs
Compile a TypeScript or JavaScript file to a standalone executable
"All imported files and packages are bundled into the executable, along with a copy of the Bun runtime."
I don't think deno does that?
Yes it does, that's the goal. You can also see in my example, it bundled the hello world script.
yeah but can you minify and bytecode the bun example and re-give the results
it's maybe deno does this as default
Ok, to clarify, which part of this is deno not doing?
"All imported files and packages are bundled into the executable, along with a copy of the Bun runtime."
In my example, I believe that deno is bundling the imported files and packages into the executable. It also includes the runtime, because that's how it executes.
And what difference do you think it would make in my example, where I built a hello world app? Because the code was a single
console.log statement without any importsin Bun example it says it will minify the code and bytecode will run the JSCore faster.
Does it minify the bytecode of only the code that I'm bundling, so only the single
console.log("Hello world") in my example?
FYI there is this PR that reduces binary size by a decent amount: https://github.com/denoland/deno/pull/27811
GitHub
perf: strip release binaries to minimize size, but download debug i...
This saves about 26 MB on macOS, should be similar on linux (stripping makes no difference on windows because symbols are already in a separate file).
This PR strips symbols from the release binari...
NIce, hopefully we will see it to be merged
it probably wont make it for the upcoming 2.2 release since there is ongoing discussion for some of the issues with it, but seems very likely that we will merge it in some form or another
btw I made my own little benchmark:
- @hono/hono (jsr)
- deno vs. bun
- benchmark with drill
Bun:
Deno:
Deno is faster LMAO