• stevecrox@kbin.social
      link
      fedilink
      arrow-up
      8
      ·
      edit-2
      1 year ago

      Its even better…

      In C/C++ you have to create/destroy objects, deal with pointers (**& for the win!). As a result the average C/C++ developer has to think about alot more than the average Java developer.

      In a previous job there were a lot of legacy C and C++ applications. They wanted to replace some components with Java local applications because Eclipse RCP was the new cool thing.

      So we would build it and then have 2-4 weeks for performance tuning. It basically involved one person from the team attaching Yourkit profiler and either nudging code to pure OO or C like procedural at bottleneck points.

      Every single time the result used less CPU and RAM than the C/C++ application when running through the original applications test packs. Even when those applications had gone through multiple rounds of performance tuning.

      We got given some time to figure out why, our conclusion was while any one part of the Java application would be slower, the reduced mental load lead to better performance in total.

  • CollectiveOfCells@programming.dev
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    When I worked for Amazon, someone had created a command line tool to be used in builds, but repeatedly starting up JVMs is painfully slow. I rewrote the app in C++ and it could be invoked 81 times vs one invocation of Java version.

    If I need speed, I’ll use C++. If I need developer productivity, I’ll use Ruby.

  • philm@programming.dev
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    Every language is fast, as long as it can be somehow (at least) jit compiled, and you’re not allocating much.

  • FriendOfFalcons@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    This is actually a very cool and insightful blog post. I’d have liked if the code was worked better into the written text however. I mean it didn’t dive deep into it’s Java usage or the specifics of the JVM, other than it being very well optimized for short lived objects.

    However, the precise performance numbers should be taken with a grain of salt. I’d classify this as a micro benchmark and those can often be influenced by stuff like cache locality and other small details and could look quite different on other machines.