9 ms·

It’s been the case ever since I can remember that “Java’s basically as efficient as native, it’s super fast” but all the actual java software I encounter is a s

It’s been the case ever since I can remember that “Java’s basically as efficient as native, it’s super fast” but all the actual java software I encounter is a slowish, bloated memory hog. I don’t know why, but that’s how it is.

yumaikas 7y ago
A big part of that is that this benchmark is not representative of what general software is like, not in Go, not in Java. For one thing, most software isn't churning on an array of integers. It's allocating and managing various types of objects. I haven't written a ton of java, but I suspect that the various reflection-heavy frameworks also impose a lot of overhead into the resulting software that isn't necessarily inherently part of Java the language.
- slaymaker1907 7y ago
  Reflection actually isn’t too inefficient, especially compared to using dynamic languages. I think a lot of the inefficiency is a bunch of small inefficiencies which combine together to make it very heavyweight.
  - chrisseaton 7y ago
    > Reflection actually isn’t too inefficient My understanding is that it's completely uncached. It couldn't be any less efficient.
    - kasperni 7y ago
      The overhead of, for example, invoking a method via reflection is measured in single-digit nanoseconds. Still not as fast as direct invocation, but unlikely to be a bottleneck unless you perform 10-of-millions of them per second.
      - LgWoodenBadger 7y ago
        Actually finding the method via reflection is the time consumer. Once you have the method reference, actually invoking it isn’t any different than a regular method.
        sk5t 7y ago
        Although I can't tell you why, it's been my experience that firing a simple method via reflection in both .NET and the JVM is roughly 2x the time of direct calls (or of calls via the 'dynamic' keyword in C#).
    - twic 7y ago
      Obtaining a Method object is, I think, pretty slow. But calling through one is fast - I'm not sure what happens exactly, but after some number of calls, some sort of JITting or some such happens and a call via a Method object is as fast as as through a handwritten equivalent (which does the same unpacking of arguments etc).
manishsharan 7y ago
It also depends on how much effort was put into optimizing the system. Quite often , people abuse -Xms and -Xmx by setting it to an unnecessarily high number. Or not checking their code for memory leaks. I am often surprised by how many java programmers have never run their code through a profiler.
smabie 7y ago
The style of programming for the dominant JVM languages (Java, Scala, Kotlin) involves an over reliance on churning through a lot of short-term garbage. I think this partially due to how annoying the platform is to actually use. Incredibly complex and chalk full of programmer pitfalls (like type-erasure). In fact, the majority of devs have no clue at how the JVM works, treating it as just “magic.” I would imagine that Go’s GC is worse than the tunable JVM ones, but go isn’t powerful enough that one would ever be tempted to program in an abstraction heavy style. While I would argue it takes a lot more work to program in Go ca, day Scala, I think the constraints imposed lead to better software. I for one have never seen a JVM desktop or business app that worked super well. The JVM manages to be a highly optimized efficient platform in which almost exclusively slow, laggy, and memory hungry apps are produced. With that being said, it’s a highly productive platform (if you’re using something besides Java), especially for backend business apps.
- sorokod 7y ago
  "over reliance on churning through a lot of short-term garbage" this is handled super efficiently by generational garbage collectors.
  - ec109685 7y ago
    Right, you only pay for the memory reachable when the slow / blocking part do the garbage collection runs, so a lean program that churns through small objects can be very responsive.
- cy_hauser 7y ago
  (ftf it's chock-full not chalk full.)
- deschutes 7y ago
  To my understanding, all of jetbrains products run on the jvm. They work pretty well although I wouldn't characterize them as lean.
  - smabie 7y ago
TOGoS 7y ago
Java has the misfortune (especially in older versions of the language) of limited syntax that encourages bloated frameworks that promise to marginally decrease boilerplate, combined with a VM that's robust enough to actually handle the bloat fairly gracefully. If you ignore that stuff and write Java programs in a straightforward way (accepting its verbosity, or possibly using code generation instead of runtime frameworks in places where lisp folks would use a bunch of macros), and avoid unnecessary heap allocations, they can be pretty fast.
- AtlasBarfed 7y ago
  Verbosity: use Groovy with CompileStatic.
pron 7y ago
I doubt that's true. The actual Java software you encounter includes much of Amazon, Apple, Google, and Netflix. I mean, everything is relative, but it's faster than Go and less bloated (what does that even mean?) than Python or JS.
- scarface74 7y ago
  I’m not saying Java is slow or fast, but just because it is used by large companies doesn’t say anything. They have the resources to throw hardware at it.
  - pron 7y ago
    They also need to serve a lot of people. Java also uses less energy than Go, significantly less than JS, and a whole lot less than Python [1]. Those big companies also need to care about that (not to mention about Java's combination of performance, productivity, serviceability and stability). [1]: https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
    - scarface74 7y ago
      Apple uses (used?) WebObjects for the iTunes/App Store. I doubt they are using the latest most finely tuned version Java for it.
- shantly 7y ago
  I just mean all the developer tools, consumer-facing GUI software, and a wide variety of server software & daemons. All of those that I’ve seen in Java over the last 20ish years. Perhaps the tech giants are all writing Java that’s nearly as low-footprint and fast as C, I dunno, no way to tell from this side. I can only sample programs I’ve had access to. [edit] bloated = much higher memory requirements than I’d expect for what they’re doing (yes I know how to configure jvm memory and such), affects the performance of other software on the same machine more than I’d expect, if running on battery, fairly likely to chew through it while doing nothing.
jayd16 7y ago
Like what? What do you encounter that's a slow Java app? It's really fallen out of favor in the desktop app space so it's probably not that.
- ptx 7y ago
  It fell out of favor because all the Java apps people encountered in the desktop app space were slow.
  - jayd16 7y ago
    I think it has much more to do with the fact that there isn't a really great desktop UI framework for Java. Electron is a slow memory hog and people tolerate that fine.
    - vips7L 7y ago
      JavaFX is alright. Its just not what JS/webdevs are used to.
  - nobleach 7y ago
    The only Java deskop app I've used that doesn't feel bloated is Charles. It _still_ has that Swing "almost looks like OSX" look to it but otherwise, it's completely usable. I use IntelliJ nearly every day, and while it's insanely powerful, it feels so incredibly bloated. I'm running on a 6th gen Thinkpad X1C (Arch Linux), a 2017 Macbook Pro (both with 16G of RAM) and a brand new Ryzen 7 with 32G of Ram. It just isn't snappy. I've always wanted to write a JavaFX app and compare it across platforms. I've seen some really nice demos.
    - jayd16 7y ago
      The slowest part of IntelliJ is scanning the project. I much prefer Rider over VisualStudio though. It doesn't feel any slower to me despite being Java.
zmmmmm 7y ago
I think it's a combo of several different things, some of them real, but mostly wrong: - most people judge by their personal realtime interaction with Java which is generally dominated by startup times (command line / desktop) or UI (Swing) both of which are Java's weak points. They don't have any way to experience the efficiency that happens silently under the covers after JIT has occurred in a server side application so they assume it doesn't exist. - a huge amount of Java software is enterprise garbage that would be garbage in every lanuage - Java just happened to win the lottery of adoption there - the ecosystem DOES encourage sucking in a HUGE amount of libraries. Java developers will pull in a 10mb dependency because it gives them a just slightly nicer API to something because doing that is so easy. But the result is enormous runtime library footprint. About 80% of this is perception bias, about 20% of it is real IMHO. Java is amazing to use for high performance work, and it really does compete with fully compiled languages while maintaining many of the benefits of interpreted languages (true cross platform, hot-swap code, debugging, etc.)

yumaikas 7y ago

A big part of that is that this benchmark is not representative of what general software is like, not in Go, not in Java. For one thing, most software isn't churning on an array of integers. It's allocating and managing various types of objects. I haven't written a ton of java, but I suspect that the various reflection-heavy frameworks also impose a lot of overhead into the resulting software that isn't necessarily inherently part of Java the language.

slaymaker1907 7y ago
Reflection actually isn’t too inefficient, especially compared to using dynamic languages. I think a lot of the inefficiency is a bunch of small inefficiencies which combine together to make it very heavyweight.
- chrisseaton 7y ago
  > Reflection actually isn’t too inefficient My understanding is that it's completely uncached. It couldn't be any less efficient.
  - kasperni 7y ago
    The overhead of, for example, invoking a method via reflection is measured in single-digit nanoseconds. Still not as fast as direct invocation, but unlikely to be a bottleneck unless you perform 10-of-millions of them per second.
    - LgWoodenBadger 7y ago
      Actually finding the method via reflection is the time consumer. Once you have the method reference, actually invoking it isn’t any different than a regular method.
      - sk5t 7y ago
        Although I can't tell you why, it's been my experience that firing a simple method via reflection in both .NET and the JVM is roughly 2x the time of direct calls (or of calls via the 'dynamic' keyword in C#).
  - twic 7y ago
    Obtaining a Method object is, I think, pretty slow. But calling through one is fast - I'm not sure what happens exactly, but after some number of calls, some sort of JITting or some such happens and a call via a Method object is as fast as as through a handwritten equivalent (which does the same unpacking of arguments etc).

manishsharan 7y ago

It also depends on how much effort was put into optimizing the system. Quite often , people abuse -Xms and -Xmx by setting it to an unnecessarily high number. Or not checking their code for memory leaks. I am often surprised by how many java programmers have never run their code through a profiler.

smabie 7y ago

The style of programming for the dominant JVM languages (Java, Scala, Kotlin) involves an over reliance on churning through a lot of short-term garbage. I think this partially due to how annoying the platform is to actually use. Incredibly complex and chalk full of programmer pitfalls (like type-erasure). In fact, the majority of devs have no clue at how the JVM works, treating it as just “magic.” I would imagine that Go’s GC is worse than the tunable JVM ones, but go isn’t powerful enough that one would ever be tempted to program in an abstraction heavy style. While I would argue it takes a lot more work to program in Go ca, day Scala, I think the constraints imposed lead to better software. I for one have never seen a JVM desktop or business app that worked super well. The JVM manages to be a highly optimized efficient platform in which almost exclusively slow, laggy, and memory hungry apps are produced. With that being said, it’s a highly productive platform (if you’re using something besides Java), especially for backend business apps.

sorokod 7y ago
"over reliance on churning through a lot of short-term garbage" this is handled super efficiently by generational garbage collectors.
- ec109685 7y ago
  Right, you only pay for the memory reachable when the slow / blocking part do the garbage collection runs, so a lean program that churns through small objects can be very responsive.
cy_hauser 7y ago
(ftf it's chock-full not chalk full.)
deschutes 7y ago
To my understanding, all of jetbrains products run on the jvm. They work pretty well although I wouldn't characterize them as lean.
- smabie 7y ago

TOGoS 7y ago

Java has the misfortune (especially in older versions of the language) of limited syntax that encourages bloated frameworks that promise to marginally decrease boilerplate, combined with a VM that's robust enough to actually handle the bloat fairly gracefully. If you ignore that stuff and write Java programs in a straightforward way (accepting its verbosity, or possibly using code generation instead of runtime frameworks in places where lisp folks would use a bunch of macros), and avoid unnecessary heap allocations, they can be pretty fast.

AtlasBarfed 7y ago
Verbosity: use Groovy with CompileStatic.

pron 7y ago

I doubt that's true. The actual Java software you encounter includes much of Amazon, Apple, Google, and Netflix. I mean, everything is relative, but it's faster than Go and less bloated (what does that even mean?) than Python or JS.

scarface74 7y ago
I’m not saying Java is slow or fast, but just because it is used by large companies doesn’t say anything. They have the resources to throw hardware at it.
- pron 7y ago
  They also need to serve a lot of people. Java also uses less energy than Go, significantly less than JS, and a whole lot less than Python [1]. Those big companies also need to care about that (not to mention about Java's combination of performance, productivity, serviceability and stability). [1]: https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
  - scarface74 7y ago
    Apple uses (used?) WebObjects for the iTunes/App Store. I doubt they are using the latest most finely tuned version Java for it.
shantly 7y ago
I just mean all the developer tools, consumer-facing GUI software, and a wide variety of server software & daemons. All of those that I’ve seen in Java over the last 20ish years. Perhaps the tech giants are all writing Java that’s nearly as low-footprint and fast as C, I dunno, no way to tell from this side. I can only sample programs I’ve had access to. [edit] bloated = much higher memory requirements than I’d expect for what they’re doing (yes I know how to configure jvm memory and such), affects the performance of other software on the same machine more than I’d expect, if running on battery, fairly likely to chew through it while doing nothing.

jayd16 7y ago

Like what? What do you encounter that's a slow Java app? It's really fallen out of favor in the desktop app space so it's probably not that.

ptx 7y ago
It fell out of favor because all the Java apps people encountered in the desktop app space were slow.
- jayd16 7y ago
  I think it has much more to do with the fact that there isn't a really great desktop UI framework for Java. Electron is a slow memory hog and people tolerate that fine.
  - vips7L 7y ago
    JavaFX is alright. Its just not what JS/webdevs are used to.
- nobleach 7y ago
  The only Java deskop app I've used that doesn't feel bloated is Charles. It _still_ has that Swing "almost looks like OSX" look to it but otherwise, it's completely usable. I use IntelliJ nearly every day, and while it's insanely powerful, it feels so incredibly bloated. I'm running on a 6th gen Thinkpad X1C (Arch Linux), a 2017 Macbook Pro (both with 16G of RAM) and a brand new Ryzen 7 with 32G of Ram. It just isn't snappy. I've always wanted to write a JavaFX app and compare it across platforms. I've seen some really nice demos.
  - jayd16 7y ago
    The slowest part of IntelliJ is scanning the project. I much prefer Rider over VisualStudio though. It doesn't feel any slower to me despite being Java.

zmmmmm 7y ago

I think it's a combo of several different things, some of them real, but mostly wrong: - most people judge by their personal realtime interaction with Java which is generally dominated by startup times (command line / desktop) or UI (Swing) both of which are Java's weak points. They don't have any way to experience the efficiency that happens silently under the covers after JIT has occurred in a server side application so they assume it doesn't exist. - a huge amount of Java software is enterprise garbage that would be garbage in every lanuage - Java just happened to win the lottery of adoption there - the ecosystem DOES encourage sucking in a HUGE amount of libraries. Java developers will pull in a 10mb dependency because it gives them a just slightly nicer API to something because doing that is so easy. But the result is enormous runtime library footprint. About 80% of this is perception bias, about 20% of it is real IMHO. Java is amazing to use for high performance work, and it really does compete with fully compiled languages while maintaining many of the benefits of interpreted languages (true cross platform, hot-swap code, debugging, etc.)