4 ms·

So they are writing code similar to this: object array for( large ) { object n = new object //heap allocation if( n == array[i]) //do something w

So they are writing code similar to this: object array for( large ) { object n = new object //heap allocation if( n == array[i]) //do something with n //do stuff //n is not needed anymore }

Afforess 12y ago
Not quite. The post describes the usage of a "BlockPos" vector that describes the x,y,z (and presumably rotation/yaw/pitch) for a world position. I think previously they were using primitive integers and floats, and have migrated to using an immutable object instead. Because of the amount of coordinate lookups each engine tick, this generates a vast number of objects.
- Groxx 12y ago
  It also makes this claim, which seems suspect[1]: >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. [1] or expose .equals(x,y,z) (assuming BlockPos is just an object wrapper around [x,y,z]). Granted, it kinda defeats the purpose of a completely-encapsulated object, but ya gotta do what ya gotta do when it comes to performance.
  - ObviousScience 12y ago
    The problem is that if a block updates, it triggers something like 6 additional block updates - those +/- 1 in each of the cardinal directions. These block updates in turn may generate yet more block updates. There are two ways to make look-up or other utility calls with this fact: by either feeding in raw integer values based on the original values, or by allocating 6 additional objects. In both cases, you need to maintain your original reference position when generating the additional values, because the position is needed to generate all the values, so can't be changed to generate the first one. The integers being passed at a low level saves on the amount of objects being allocated. This has the potential to end up generating a lot of objects in response to certain kinds of events in the game world.
  - thedufer 12y ago
    > So if you need to check another position around the current one Key word "around". If a coordinate object is immutable, then doing operations on a neighboring one requires another allocation for the new coordinate object. Unless you're suggesting having a coordinate version of every function that operates on a BlockPos, in which case there's no point at all in BlockPos existing.
    - Groxx 12y ago
      That's basically what I'm suggesting. Use it only on hot paths you've profiled, maintain purity elsewhere. Java pretty much requires you to make concessions if you're trying to get maximum performance. Similarly: it has a garbage collector, but there are plenty of places where an object pool will out-perform it. Deliberately breaking / re-implementing part of the language for performance reasons.
    - deleted 12y ago
      [deleted]
teamonkey 12y ago
I haven't seen the code, obviously, but Minecraft has a lot of functionality similar to cellular automata. That is, checking the contents of adjacent cells. I imagine the code went from v1 = Cell.testPos(x-1,y,z); v2 = Cell.testPos(x+1,y,z); v3 = Cell.testPos(x,y-1,z); ... To v1 = Cell.testPos(new BlockPos(block.x-1,block.y,block.z)); v2 = Cell.testPos(new BlockPos(block.x+1,block.y,block.z)); v3 = Cell.testPos(new BlockPos(block.x,block.y-1,block.z)); ...

So they are writing code similar to this: object array for( large ) { object n = new object //heap allocation if( n == array[i]) //do something with n //do stuff //n is not needed anymore }

Afforess 12y ago

Not quite. The post describes the usage of a "BlockPos" vector that describes the x,y,z (and presumably rotation/yaw/pitch) for a world position. I think previously they were using primitive integers and floats, and have migrated to using an immutable object instead. Because of the amount of coordinate lookups each engine tick, this generates a vast number of objects.

Groxx 12y ago
It also makes this claim, which seems suspect[1]: >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. [1] or expose .equals(x,y,z) (assuming BlockPos is just an object wrapper around [x,y,z]). Granted, it kinda defeats the purpose of a completely-encapsulated object, but ya gotta do what ya gotta do when it comes to performance.
- ObviousScience 12y ago
  The problem is that if a block updates, it triggers something like 6 additional block updates - those +/- 1 in each of the cardinal directions. These block updates in turn may generate yet more block updates. There are two ways to make look-up or other utility calls with this fact: by either feeding in raw integer values based on the original values, or by allocating 6 additional objects. In both cases, you need to maintain your original reference position when generating the additional values, because the position is needed to generate all the values, so can't be changed to generate the first one. The integers being passed at a low level saves on the amount of objects being allocated. This has the potential to end up generating a lot of objects in response to certain kinds of events in the game world.
- thedufer 12y ago
  > So if you need to check another position around the current one Key word "around". If a coordinate object is immutable, then doing operations on a neighboring one requires another allocation for the new coordinate object. Unless you're suggesting having a coordinate version of every function that operates on a BlockPos, in which case there's no point at all in BlockPos existing.
  - Groxx 12y ago
    That's basically what I'm suggesting. Use it only on hot paths you've profiled, maintain purity elsewhere. Java pretty much requires you to make concessions if you're trying to get maximum performance. Similarly: it has a garbage collector, but there are plenty of places where an object pool will out-perform it. Deliberately breaking / re-implementing part of the language for performance reasons.
  - deleted 12y ago
    [deleted]

teamonkey 12y ago

I haven't seen the code, obviously, but Minecraft has a lot of functionality similar to cellular automata. That is, checking the contents of adjacent cells. I imagine the code went from v1 = Cell.testPos(x-1,y,z); v2 = Cell.testPos(x+1,y,z); v3 = Cell.testPos(x,y-1,z); ... To v1 = Cell.testPos(new BlockPos(block.x-1,block.y,block.z)); v2 = Cell.testPos(new BlockPos(block.x+1,block.y,block.z)); v3 = Cell.testPos(new BlockPos(block.x,block.y-1,block.z)); ...