4 ms·

And the final result was that the two languages had roughly the same performance, which may surprise folks that believe Java is still a slow language.

• bluejekyll 10y ago
  It hasn't been slow since basically 1.3 when HotSpot became default.
  • pjmlp 10y ago
    Urban legends tend to live forever.
    • aisofteng 10y ago
      I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are. In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors: 1. Its high level abstractions are computationally expensive. Sometimes this idea is supported by saying that garbage collection is very slow, sometimes by saying that the inability to directly manage memory means that it is done inefficiently, perhaps even inescapably so. 2. Compiling a program to an intermediary language that is not assembly but must be instead executed by something else (in this case, the JVM) must be slow.
      • wuch 10y ago
        Controlling memory layout is one area that is very important for performance, where Java does not exactly shines. You essentially have to store your data in arrays of primitive types, to avoid memory overhead of objects (pointer to class, lock, gc bits) and additional indirection during access. While not exactly impossible, Java makes it quite inconvenient and costly to write code that takes control of memory layout.
        • pjmlp 10y ago
          Hence why there are ongoing improvements targeted to Java 10, to change exactly that. Until then there are the IBM and Azul extensions, off heap memory, or optimizing in native code that 1% after using the profiler, where it really matters.
        • therpe1 10y ago
          It's worth pointing out that: 1) Controlling memory layout is not as big a deal as people think. The JVM is highly optimized (really it's probably the most optimized system ever devised) for allocating and deallocating objects on the heap. 2) It is in fact possible to control memory layout today because Java has access to offheap memory where you can have all the control you want. This has actually been the case for nearly half a decade but for some reason a lot of people are convinced that "big arrays" can knock over the JVM.
      • eru 10y ago
        Number 2 is especially funny: isn't LLVM doing something similar-ish for C++?
        • pjmlp 10y ago
          Kind of. In any case, bytecode as executable format, goes back to the early days when CPU were microprogrammed. It was also a common approach on mainframes, with OS/400 being the best example.
    • akvadrako 10y ago
      Java is still slow in practice, particularly due to poor startup times, due to things like class scanning and the ecosystem of bloated libraries.
      • pjmlp 10y ago
        Only by those that don't have experience in Java tooling. High startup costs you say? Then don't use OpenJDK. Get an AOT compiler to native code like Excelsior Jet or switch to a JVM that supports both AOT compilation to native code and JIT code caching like IBM J9 or Azul. class scanning ? Again stop using OpenJDK and switch to a JVM that supports class sharing across VM instances like IBM J9. For those that don't want ever to use anything other than OpenJDK, some of those features might eventually come there, like the newly introduced support for AOT compilation of the base module for Linux x64. With everything else planned for Java 10. Bloated libraries? Well, there are bloated libraries in any programming language. And by any change you are thinking of JEE, I doubt you had the pleasure to use C or C++ alongside DCOM, CORBA and SUN RPC, at enterprise level to fully understand the relief it was to change to JEE.
      • cturner 10y ago
        Java is not slow in practice. Many top trading systems have been written in it, including the excellent and widely licensed nasdaq architecture (omx, singapore, asx, swx, etc) and the independently designed Lmax Disruptor. You do not have to use any library you don't want to. there is nothing stopping you from building everything in preallocated byte arrays, and never triggering gc. Nio2 is fast. Jvm is a leading foundation of fast, complex distributed systems, particularly if you need multiple programmers working on a single source tree.
        • rusk 10y ago
          Yes Java is as quick as anything else once it is up and running; the point GP was making was getting to this warmed up state is what makes people perceive java as slow.
          • pjmlp 10y ago
• rusk 10y ago
  The reputation for slowness comes from the warm-up time. There is always a very noticeable delay starting even a simple java app; whereas a native binary is relatively instantaneous. There are tricks to alleviate this issue in java (e.g. you can keep a JVM running in the background using tool like nailgun) but the default vanilla java behaviour is what most people will be familiar with.
  • mcguire 10y ago
    I wonder how much work the JVM does to handle jit-compilation and deoptimization when use patterns change.