3 ms·
Your other choices are: - Never GC via using object pools. This code is nastier than C++ because Java is not intended to be used this way. - GC whenever neede
by zlynx 5y ago
Your other choices are:
- Never GC via using object pools. This code is nastier than C++ because Java is not intended to be used this way.
- GC whenever needed randomly. The game will just pause occasionally. Very annoying as a player.
- Write the actual game in C++. Make a few JNI calls here and there. On feature phones I only remember this being possible for some vendor apps.
- banana_giraffe 5y agoIf these phones were still around, I'd imagine there'd be another option now: - Write your game in C++ and transpile it to Java using some fancy framework that dances around never using GC.
- kllrnohj 5y agoYou'd have to do something like allocate a single byte[] for everything you'll ever need, and reading & writing data would just be a constant tax since you can't just in-place cast that to an int or whatever. It wouldn't be very fun.
- zlynx 5y agoBut it would be transpiled so the programmer would never need to look at the very ugly stuff. The idea reminds me of the original asm.js
- kaba0 5y agoDepends on when. If we are talking about modern day JVM, than even the non-latency optimized default GC would have <10ms stop-the-world pauses for up to gigantic allocation rates, much less for the presumably minor one of a simple game. And then there are two latency optimized ones, Shenandoah and ZGC, with the latter having <1ms, meaning that your OS introduces more latency with thread switches. So I think writing a game while profiling allocation rates and paying a bit of attention to not spam new everywhere, one should get decent performance without any framedrops. At most, optimize the hot loops with primitives, arrays.