5 ms·

I guess you see a lot of such articles because of comments like yours - lots of people still think Java is generically slow or Java code is always bloated, desp

I guess you see a lot of such articles because of comments like yours - lots of people still think Java is generically slow or Java code is always bloated, despite not having used it for 10 years or more. Whilst such views persist, there will be articles arguing they're false based on newer data. Nobody writes "C is not slow" articles any more, but I remember a time when there were people who believed C++ was inherently slower than C. Maybe some such people still exist! I don't see much talk like that anymore though. With respect to bloated code, the 1990's and early 2000's also saw things like DCOM and other C++ bloat-zones. It's not really to do with the language. The presence of bloat in enterprise apps is more to do with the lack of competition (bespoke apps are by definition monopolies), the frequent lack of deadline pressure (deadlines are invariably artificial) and the inflexible team sizes (over-engineering is incentivised by the need to retain a nice safe corporate job). The fact that enterprise software and Java go hand in hand speaks more to the lack of competition in the space Java plays in, than anything about the language itself.

pjmlp 10y ago
So many memories... Yeah, I remember the days when junior Assembly coders could easily write better code than any C compiler for home computers. Or the days when the arguments that are now used against Java, Go, Swift and many others where used against Turbo Pascal, C, C++, Modula-2, Basic compilers. The more things change, the more they stay the same, I guess.
userbinator 10y ago
despite not having used it for 10 years or more I just don't write code in Java anymore --- I still need to use some Java apps, and the difference remains obvious. The other thing I've noticed is that a lot of those "Java is actually fast" articles are [1] entirely words about all the fancy optimisations JVMs do with no real numbers, [2] comparing Java with previous versions of itself, [3] comparing Java with highly dynamic languages like JavaScript, Python, or Ruby, or [4] microbenchmarks designed to specifically highlight certain JVM optimisations. but I remember a time when there were people who believed C++ was inherently slower than C. The C++ vs C case is slightly different, because C++ is essentially an extension of C. Some features like iostreams vs stdio are objectively slower on the C++ side, and efficient C++ code usually tends to look a lot like C. Those who say C++ is slower are referring to the "overuse" of C++ features that add overhead. As the benchmarks posted below show, even carefully written and optimised Java that looks like C is slower than C.
- sievebrain 10y ago
  Well, here is a paper you may find useful: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H... They write the same program in C++, Java, Scala and Go, then compare performance both before and after optimisation. They key part that shows Java can be as fast as C++ is V.E "Java tunings": Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well. The tunings he applied are not exotic, but would not be used in most code unless it was actually performance sensitive. For instance he chose better starting sizes in ArrayLists and replaced boxing collections with more optimal ones (presumably from GNU Trove). Of course, that is a comparison against the original C++. Later in the paper it is shown that Google were able to optimize the C++ version heavily and it then beat the Java version again, however, apparently the optimised version relied on data structures so exotic that they're Google proprietary and they chose not to open source them, so I'm not sure that'd be reflective of the experience of the average C++ developer.

pjmlp 10y ago

So many memories... Yeah, I remember the days when junior Assembly coders could easily write better code than any C compiler for home computers. Or the days when the arguments that are now used against Java, Go, Swift and many others where used against Turbo Pascal, C, C++, Modula-2, Basic compilers. The more things change, the more they stay the same, I guess.

userbinator 10y ago

despite not having used it for 10 years or more I just don't write code in Java anymore --- I still need to use some Java apps, and the difference remains obvious. The other thing I've noticed is that a lot of those "Java is actually fast" articles are [1] entirely words about all the fancy optimisations JVMs do with no real numbers, [2] comparing Java with previous versions of itself, [3] comparing Java with highly dynamic languages like JavaScript, Python, or Ruby, or [4] microbenchmarks designed to specifically highlight certain JVM optimisations. but I remember a time when there were people who believed C++ was inherently slower than C. The C++ vs C case is slightly different, because C++ is essentially an extension of C. Some features like iostreams vs stdio are objectively slower on the C++ side, and efficient C++ code usually tends to look a lot like C. Those who say C++ is slower are referring to the "overuse" of C++ features that add overhead. As the benchmarks posted below show, even carefully written and optimised Java that looks like C is slower than C.

sievebrain 10y ago
Well, here is a paper you may find useful: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H... They write the same program in C++, Java, Scala and Go, then compare performance both before and after optimisation. They key part that shows Java can be as fast as C++ is V.E "Java tunings": Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well. The tunings he applied are not exotic, but would not be used in most code unless it was actually performance sensitive. For instance he chose better starting sizes in ArrayLists and replaced boxing collections with more optimal ones (presumably from GNU Trove). Of course, that is a comparison against the original C++. Later in the paper it is shown that Google were able to optimize the C++ version heavily and it then beat the Java version again, however, apparently the optimised version relied on data structures so exotic that they're Google proprietary and they chose not to open source them, so I'm not sure that'd be reflective of the experience of the average C++ developer.