spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Maybe the biggest and the ugliest problem is the memory allocation. Currently the game allocates (and throws away immediately) 50 MB/sec when standing still and up to 200 MB/sec when moving. That is just crazy.

Zitat

[...]
5. Why is 1.8 allocating so much memory?
This is the best part - over 90% of the memory allocation is not needed at all. Most of the memory is probably allocated to make the life of the developers easier.
- There are huge amounts of objects which are allocated and discarded milliseconds later.
- All internal methods which used parameters (x, y, z) are now converted to one parameter (BlockPos) which is immutable. So if you need to check another position around the current one you have to allocate a new BlockPos or invent some object cache which will probaby be slower. This alone is a huge memory waste.
[...]

Zitat

The general trend is that the developers do not care that much about memory allocation and use "best industry practices" without understanding the consequences. The standard reasoning being "immutables are good", "allocating new memory is faster than caching", "the garbage collector is so good these days" and so on.

Zitat

Games can be either fast or extensible, pick one. I'll let you knife-fight it out with the ones demanding a plugin API.

Zitat

Well, there has been a big movement lately about zero-cost abstractions (see Rust or C++11) that aim to have the cake and eat it too, but in Java yep you can either have slow code or ugly code, mainly because someone in 1994 decided that the stack wasn't worth using and that ignoring that memory exists was a good idea.
Also, "zero cost" abstractions usually imply increased developer effort anyway.