Meshing software is a typical program where you need C++ and where Java is a terrible choice.
By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.
Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.
In some algorithms, other data structures such as trees, may be used used as intermediate formats, but there too the options to use malloc/gc allocated nodes vs alternatives is similar in a GC'd vs a non-GC'd language.
In general, good GC's often outperform malloc/free. Because GC's are amenable to parallelization in the background, and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.
I converted that code to C++ and recently added a custom allocator to improve performance even further. The result is now functionally equivalent, but about 5 times faster.
No. That's on synthetic benchmarks. Run a real server and you see that Java shits its pants while a C++ service is running rings around it.
That's because memory/cache fragmentation and usage is vastly more important in 2019 than CPU cycles.
And in this case, the author does need cpp speed.
Because you can be a lot more productive if you are not extremely constrained by speed.
The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes.
Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.
