TileEntities and their issues.

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord

Elder Jürd

New Member
Jul 29, 2019
16
0
0
Hello FTB community.

As a modder, now i am confused, mainly because what everyone says, and is true, tileEntities are the solution and the problem. So, to be a good modder i need to avoid using tileEntities as much as i can. OK! no problem... although...

I suppose tileEntities that do not tick cause less lag, isn't it?

let's say i got 1024 tileEntities, how will that affect the performance of...?

- normal gameplay?
- chunk loading-unloading?

if...?

- they don't tick and store a lot of variables?
- they tick and store few variables?

As your guys may eb experienced on this, you might help me A LOT in the way i may program my features.

Thank you guys for your time.
 

McJty

Over-Achiever
Mod Developer
May 13, 2014
2,015
2,519
228
twitter.com
Normally a block in the world can only store the block id that is being used (i.e. cobble, dirt, ...) and 4 bits of metadata. That metadata is often used for color (stained hardened clay) or orientation (in case of chests).

That's all there is. If you need to store more then that then you *have* to use tile entities.

It is not a matter of performance. It is a matter of having a place to store your stuff. Chests, furnaces, ... machines all need tile entities.

A tile entity that doesn't 'tick' doesn't cause performance issues with regards to cpu usage. But of course tile entities do consume memory and make loading the chunk back take a little bit longer.

But don't worry. Use a tile entity if you need to store more information then what you can store in 16+4 bits.
 
  • Like
Reactions: Elder Jürd

Elder Jürd

New Member
Jul 29, 2019
16
0
0
Normally a block in the world can only store the block id that is being used (i.e. cobble, dirt, ...) and 4 bits of metadata. That metadata is often used for color (stained hardened clay) or orientation (in case of chests).

But don't worry. Use a tile entity if you need to store more information then what you can store in 16+4 bits.

Thanks for the quick answer.

Right. Knowing this, in my mod i have developped a series of trees that generate an insane amount of tileEntities that tick and store up to 20 variables, to make trees grow in real time.

I need feedback on this but as far as i know, because they only do things once each 2 min, i though that would reduce the performance issues. It's been working good for up to 10 or 20 trees. Afterwards, it starts to hit performance when loading-unloading chunks, although the gameplay is not affected.

edit: if you look at the mod page in my signature you will understand XD
 

McJty

Over-Achiever
Mod Developer
May 13, 2014
2,015
2,519
228
twitter.com
How many tile entities for a single tree?

There may be other ways to solve this. You can for example store data per dimension which is unrelated to blocks or chunks. Of course if you do that you would have to do your own management of that data and that is a bit more complicated.
 

Elder Jürd

New Member
Jul 29, 2019
16
0
0
depending on the time i let him divide, goes to 1024+;

i was thinking on a single tile entity that ticks, wich checks the path made with tileEntities that don't tick.

i'm not affraid of programming. But i lack some java for now.
 

ratchet freak

Well-Known Member
Nov 11, 2012
1,198
243
79
I don't really see anything with the trees that need TEs; your machines do if you want to store the inventory (fun fact: the vanilla crafting table isn't a TE)

but the trees can be done using just the 4bits of meta data and a different ID for each block
 

Elder Jürd

New Member
Jul 29, 2019
16
0
0
I don't really see anything with the trees that need TEs; your machines do if you want to store the inventory (fun fact: the vanilla crafting table isn't a TE)

but the trees can be done using just the 4bits of meta data and a different ID for each block

These trees that are constantly updating and feature some generation changes need more than 4 bits. They are quite complicated.

edit: and that's why the crafting table cannot store its contents xD
 

ratchet freak

Well-Known Member
Nov 11, 2012
1,198
243
79
These trees that are constantly updating and feature some generation changes need more than 4 bits. They are quite complicated.

edit: and that's why the crafting table cannot store its contents xD
it could then all be stored in a single "root" TE in the root of the tree that is the only one ticking,
 

Elder Jürd

New Member
Jul 29, 2019
16
0
0
it could then all be stored in a single "root" TE in the root of the tree that is the only one ticking,
that's what i thought :D

although i wanted to ask because i got an idea that needs tileentities that don't actually tick, but store the coordinates of the root tile so they can know who created them. Is that affordable for my mod?

edit, also they may have some functions that will be fired by the root tile
 

ratchet freak

Well-Known Member
Nov 11, 2012
1,198
243
79
that's what i thought :D

although i wanted to ask because i got an idea that needs tileentities that don't actually tick, but store the coordinates of the root tile so they can know who created them. Is that affordable for my mod?

edit, also they may have some functions that will be fired by the root tile
if you don't need the storage then just put those methods in the block class
 

GreenZombie

New Member
Jul 29, 2019
2,402
-1
0
Of course the mere existence of tile entities effects performance.
The normal arrangement of chunk data means that whenever minecraft needs to know what is at a particular location its a simple array lookup. Any tile entity means that a lookup now has to additionally can a list. So you are trading an O(1) operation with an O(n) operation.
Once you start scaling to 1000's of TEs, and consider that at 100fps you are now forcing minecraft to scan those lists 100 times per second. And that each time minecraft has to render a chunk it has to perform the scan FOR EACH tile entity, the real render cost of tile entities becomes O(n²) (assuming Mojang hasn't tried to optimise this, as this situation never occurs in vanilla so would not be on their list of improvements to make. *

And thats not counting tick issues: more than 10s of TEs per chunk does become a problem even if they are passive. Don't.

--
* This was stated perhaps more strongly than I intended. I do not *know* that the TE render scan would reduce to O(n²) - I merely suspect it as the probable worse case. Empirical tests or examination of MCs code would be required to see if hashmaps or other steps are taken to attempt to optimise the rendering of large numbers of TEs per chunk)
 
Last edited:
  • Like
Reactions: FyberOptic

ratchet freak

Well-Known Member
Nov 11, 2012
1,198
243
79
Of course the mere existence of tile entities effects performance.
The normal arrangement of chunk data means that whenever minecraft needs to know what is at a particular location its a simple array lookup. Any tile entity means that a lookup now has to additionally can a list. So you are trading an O(1) operation with an O(n) operation.
Once you start scaling to 1000's of TEs, and consider that at 100fps you are now forcing minecraft to scan those lists 100 times per second. And that each time minecraft has to render a chunk it has to perform the scan FOR EACH tile entity, the real render cost of tile entities becomes O(n²).

And thats not counting tick issues: more than 10s of TEs per chunk does become a problem even if they are passive. Don't.
MC scans rather than using a hashmap?
 

GreenZombie

New Member
Jul 29, 2019
2,402
-1
0
MC scans rather than using a hashmap?

My comments were based on observations of the anvil map data structures. Certainly there are ways to optimize the scan but they would all tend to add a large overhead to what should, in the normal case (a small number of TEs) be a quick operation and would require the construction of said hashmaps as each chunk was loaded.

So yes, O(n²) is a worst case conjecture, based on the observation thats what the published data structures support, and that Minecrafts own developers would never have had the incentive to optimise for the unusual case presented here.
 

ratchet freak

Well-Known Member
Nov 11, 2012
1,198
243
79
My comments were based on observations of the anvil map data structures. Certainly there are ways to optimize the scan but they would all tend to add a large overhead to what should, in the normal case (a small number of TEs) be a quick operation and would require the construction of said hashmaps as each chunk was loaded.

So yes, O(n²) is a worst case conjecture, based on the observation thats what the published data structures support, and that Minecrafts own developers would never have had the incentive to optimise for the unusual case presented here.
but during loading MC could put it in a hashmap mapped to coordinates for O(1) access, it has to be loaded anyway and pushing into a hashset is cheap
 

Elder Jürd

New Member
Jul 29, 2019
16
0
0
That said, i remind you that the performances seems not affected for a pretty large number of entities when you are standing next to them. The problem starts at loading and unloading chunks, otherwise it's not noticeable :/
 

GreenZombie

New Member
Jul 29, 2019
2,402
-1
0
Thaumcraft was creating 10k tile entities in a game that had lagged down to 5fps due to high server avg tick. Opis indicated he total time spent ticking them was merely hundreds of microseconds.

Upgrading to the latest version that replaced them with plain blocks sees 100fps again and a 5ms avg tick.

The measurable costs were low. The bulk of the impact just seemed to be in having that many tile entities.

But this discussion is largely moot. Simply ceate some test cases where you generate thousands of TEs and report how it scales the avg tick and FPS. Science can answer this more accurately than opinions.
 

Elder Jürd

New Member
Jul 29, 2019
16
0
0
Thaumcraft was creating 10k tile entities in a game that had lagged down to 5fps due to high server avg tick. Opis indicated he total time spent ticking them was merely hundreds of microseconds.

Upgrading to the latest version that replaced them with plain blocks sees 100fps again and a 5ms avg tick.

The measurable costs were low. The bulk of the impact just seemed to be in having that many tile entities.

But this discussion is largely moot. Simply ceate some test cases where you generate thousands of TEs and report how it scales the avg tick and FPS. Science can answer this more accurately than opinions.

Totally agreed in everything.