3 ms·
It's a trade off, my understanding is that Glowstone's trade off is providing customization through APIs and mechanisms that will last. E.g. simplicity and powe
by SolarNet 9y ago
It's a trade off, my understanding is that Glowstone's trade off is providing customization through APIs and mechanisms that will last. E.g. simplicity and power at the cost of performance.
As an aside they make a claim that will be familiar to many lisp programmers. Their claim is by providing better power they will improve the average performance in the long run for their users (e.g. people who like lots of mods). Look at it this way, if you use horribly buggy edge cases to build flying machines that's going to take a ton of work for the server to simulate (minecraft flying machines often use tick perfect timings arrived at through - effectively - busy loops); if instead you used a mod that provided flying mechanics, and flying control blocks (e.g. that knew when to inject their logic) you would save a lot of performance. They may not be able to have the fastest server around, but given the things their users will use it for, theirs will probably be faster than those efficient servers in those cases.
- nly 9y agoAlso, writing a plugin system that plays nice with threads is going to be a pita.
- SpaceManiac 9y agoThis is the big one. Glowstone was designed to be a native implementation of the Bukkit API (back when it was still on top), and I assure you that that API, and thereby every plugin built against it, makes some heavy single-threadedness assumptions. Even if you conceive an API from scratch, Java hasn't the tools to prevent plugin authors from doing things they shouldn't in this regard.