Jump to content

1.8.9 getExtendedState performance - neighbor block state vs. tile entity


Zaerudath

Recommended Posts

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.

 

 

Link to comment
Share on other sites

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

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

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.

 

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.

 

Link to comment
Share on other sites

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. 

 

Link to comment
Share on other sites

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

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.