1.8.9 getExtendedState performance - neighbor block state vs. tile entity

[Zaerudath]

Question for anyone with more experience:

 

I've got some handsome blocks with connected textures that are meant to be used in quantity.  Rendering happens via an ISmartBlockModel that returns the appropriate pre-baked faces depending on neighboring blocks.

 

Each call to extended state requires a block state lookup for six to twelve (rarely more) neighboring blocks.  The additional checks are needed to know if outside corners should be rendered and are skipped if both faces on a given axis are obscured.  On my PC in debug the lookups for a single block cost about 3000 nanoseconds on average.  Calculation of the unlisted property is simply looking up an integer in an array and I don't think I can make it much faster.

 

That doesn't seem excessive, but I was wondering: how would performance compare if I instead cache this value in a tile entity? Obviously comes with some memory overhead, but it's only one hash map lookup, no ticking required, and I only have 4 bytes of data to load/save from NBT.  I believe Carpenters Blocks took a similar approach.

 

If I have a scene with lots of block updates occurring (moving pistons for example) the number of calls to getExtendedState could be much higher.  I read that Algo had a similar challenge with Chisel and Bits, but block state there is going to a couple orders of magnitude more complex, so it may be a bad example.

 

I'll have to use tile entities anyway for some of my blocks (stairs, slabs, various other parts and probably micro blocks) so that I don't completely consume all the block IDs.  If I simply use tile entities for all of them I could create more variations in appearance (especially color) without consuming more block IDs. I'd also have a more consistent way to handle block state for all my blocks.

 

That sounds nice for me, but creating blocks that essentially encourage the placement of tens of thousands of tile entities, even if they are very small in memory usage, seems...dangerous.  On the other hand, I've seen many builds on video using tile entities with reckless abandon and their worlds didn't implode (much), and hash maps are quite robust, so... why not?

 

I'm going to try it and profile it this weekend, so I guess I'll find out the hard way but I am curious if anyone else here has experience/advice to offer.

 

 

[Draco18s]

3000 nanos is NOTHING. A TE will have more overhead than that.

[jeffryfisher]

I believe that Minecraft's usual bottleneck is still bandwidth, not CPU, so put on your client-server hat and choose an approach where the server does enough thinking to minimize traffic before off-loading visual analysis to its clients.

[Zaerudath]

  On 1/22/2016 at 6:52 PM, Draco18s said:

3000 nanos is NOTHING. A TE will have more overhead than that.

 

That's been my design assumption all along. After going over the TE code last night, I'm not as certain.  Now I'm itching to benchmark it. I'll post my results.

 

  Quote

I believe that Minecraft's usual bottleneck is still bandwidth, not CPU, so put on your client-server hat and choose an approach where the server does enough thinking to minimize traffic before off-loading visual analysis to its clients.

 

Good point. I believe state for both blocks and tile entities is cached client-side and updates to either will require packets. I would assume block updates are more efficient, but in this particular case I'm not generating updates.  That's actually what led me to the question: I have to query many block states to provide extended state, potentially multiple times a second, but in the vast majority of cases none of the block states I query will have changed.

 

[Zaerudath]

Okay, I added a simple TileEntity to my block and used it to cache my extendedBlock state, which consists of two integers.  I didn't handle persistence or synchronization because it wasn't needed for this test and the state will only change when a block of similar type if broken or added within a one-block distance.

 

I built a little redstone/piston contraption on a largish platform of my blocks that I had placed earlier, and timed getExtendedState both using the TE cache, and with computing new state each time. 

 

Computing block state each time with getBlockState on neighbor blocks leveled off at 480 nanoseconds.  This is lower than before because I'm excluding data from game initialization.  When the scene first loads each call can take 20,000 ns or so but that only lasts a few seconds.  480 ns is great performance.

 

Using cached block state in TE however, leveled off at a mere 76 ns per call.  As before, times were longer at startup.  Some blocks displayed a default texture for a fraction of a second because of null TE values before everything could be initialized, but I could live with that.  I did not test over a network, but given that we're talking maybe twenty bytes of data per block (including the TE base class data) with very infrequent updates, I wouldn't expect it to be bad.

 

So, there still may be arguments for not using tile entities in quantity to hold block appearance parameters that can't fit in block ID/metadata, but performance doesn't appear to be among them. 

 

[Draco18s]

Due note that the tradeoff here is more memory required to maintain the TE.  Many things are a trade between CPU and RAM.