31–40 of 68 posts
I thought this article would be about something like https://en.wikipedia.org/wiki/Java_4K_Game_Programming_Conte... but it's more appropriately "Really Small JVM". For a simple project requiring java.net.http, using these steps produced a 23MB jlink image 23MB may seem tiny today, but depending on what that "simple project" does, in absolute terms it's still twenty-three million bytes. For comparison, a full install…
Earlier quoted context omitted.
It is remarkable how bloated modern software is. My first hard drive, back in 1988, was 30 megabytes.
If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 comp…
Fine tuning code is one thing, but installing a bloated package for one tiny feature should be well-considered at the time of implementation because every addition adds to the tech debt bill.
Earlier quoted context omitted.
It is remarkable how bloated modern software is. My first hard drive, back in 1988, was 30 megabytes.
If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 comp…
Not to mention, programs are so much more stable nowadays; I can't remember the last time my computer just locked up for no apparent reason, and I am typically pretty happy that most programs don't leak memory all over the place anymore.
Are a lot of programs bloated now? Sure, but I think I'd rather have that than having my program crash all the time because someone who didn't really know what they're doing cleared a pointer incorrectly.
GraalVM native-image is not a listed option, but I regularly use it to produce binaries that are competitive with (often better than) Go in terms of size and (start time) perf. A Clojure tool that parses, traverses and processes JSON (caro, see below) worked out to 3.2MB. I'm sure C and Rust can do better, but it's not bad compared to a JVM, and it's an order of magnitude better than the best option in the article. I…
How do they compare to go in terms of speed? Another comment also said graal native images still suffer with throughput vs using the jvm due to profile guided optimizations.
Interesting to see this as I didn't know it was so simple to compile the JDK these days. But curious how this compares to Quarkus ( https://quarkus.io/ ) which is built upon GraalVM?
Earlier quoted context omitted.
If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 comp…
In fairness, I feel like we have closer to a Gustafson's law [0] situation; individual tasks haven't gotten much faster, but it feels like we do more than we did in the 90s. The problem space has gotten so much larger than it used to be, and at some level we got to "fast enough" for things like desktop applications. Not to mention, programs are so much more stable nowadays; I can't remember the last time my computer…
When did this become the new best-practice in Java land?
Earlier quoted context omitted.
It is remarkable how bloated modern software is. My first hard drive, back in 1988, was 30 megabytes.
If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 comp…
Earlier quoted context omitted.
In fairness, I feel like we have closer to a Gustafson's law [0] situation; individual tasks haven't gotten much faster, but it feels like we do more than we did in the 90s. The problem space has gotten so much larger than it used to be, and at some level we got to "fast enough" for things like desktop applications. Not to mention, programs are so much more stable nowadays; I can't remember the last time my computer…
You'd rather have bloated programs than some random not-necessarily connected bad-thing?
I know languages like Rust and Swift have ways of safely dealing with memory without a GC, and I know Go has a non-blocking GC now, but remember that all of these things are relatively recent.
Earlier quoted context omitted.
It is remarkable how bloated modern software is. My first hard drive, back in 1988, was 30 megabytes.
If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 comp…