Apparently a hello world is like 90MB.
The Unicode part of ICU shouldn’t be that large, however (on the order of hundreds of kilobytes), it’s the locale data that’s big[1]. Does Bun implement ECMA-402 internationalization? Even without locales, one of the largest parts of ICU data is normalization and casing tables, which I think bare ECMAScript does not require. (It does mean bare ECMAScript cannot adequately process Unicode text, but meh, you get what you pay for.)
[1] https://unicode-org.github.io/icu/userguide/icu_data/buildto...
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Approximately 2,700 times bigger than it could be.
What's the point in looking at size ? I can see two:
- want to email the exe, and you have limits on mail size - want to be ecofriendly, in that case stop watching netflix for 2 hours and you'll have your megs
Although, to be fair it seems likely the executable size will shrink with time.
1. https://sergiomartinrubio.com/articles/getting-started-with-...
I assume this is a typo and they mean “does NOT”?
Originally I thought the alternative was “8MB but supply your own virtual machine.”
A pure java bytecode (bring-your-own-JVM) Hello World can be under 2KB pretty easily. Smaller than the equivalent C program. But of course, that's not including the size of your system JVM.
That's very misleading. For one, Java running native still needs a Garbage Collector, maintains Object headers which increase memory usage, can do things like reflection for configured classes, can load services via the ServiceLoader, schedule Threads and manage executors, and many other things that are "expected" to any Java application... in summary: native executables still have a Java runtime embedded into them (called Substrate VM, by the way), making them very different from C (much more like Go).
Also,notice that native Java executables still tend to have a lower "peak performance" (i.e. once a "normal" JVM has warmed up, it will almost certainly be faster than a native executable because the latter cannot do JIT compilation to take advantage of runtime profiling, like a normal JVM does).
https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-ru...
https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_...
And many more, not feeling like linking documentation from all C compilers.
In fact this is so relevant even for C, that ISO C has a special section for deployments without runtime support, named freestanding C.
"In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. There are otherwise no reserved external identitiers. Any library facilities available to a freestanding propram are implementation-defined."
From your link:
"Most of the routines in libgcc handle arithmetic operations that the target processor cannot perform directly."
You're trying to imply the Java native runtime is comparable to liggcc?? That's silly.
I’d also compare against stripped Rust binaries statically linked against musl.
ICU locale data is pretty hefty and there aren't says to trim it down.
The OpenJDK runtime with the java.base and java.desktop modules is 64 MB. Replacing Swing with SWT (leaving out the java.desktop module) gets it below 50 MB. The full OpenJDK runtime with all modules is around 128 MB. (With Java 17 on Windows.)
[1] https://docs.python.org/3/using/windows.html#windows-embedda...
0.0.2 (v8 v8.4.371.18) - file size: 15.2 MB, startup RSS: 8.4 MB current (v8 v10.6.194.9) - file size: 19.5 MB, startup RSS: 12.3 MB
so, that's roughly 30% binary size increase and 50% greater startup memory usage in 2.5 years. =/
Though Bun doesn't use Node.js I believe, there's a reference
(At least it's not JVM Hotspot...)
> The jlinked runtime using the above command is about 95Mb.
Simple programs -- like Hello World -- can indeed exclude certain parts of the JRE using jdeps, for a smaller size.
The worrying part is that this is mostly code, not dead junk simply occupying space, this is part of the code path, filling the caches, or should I say trashing the caches…