How many tickable tileentities are too many?

[Jay Avery]

I know that tickable things are obviously a lot more performance-intensive than, say, static blocks. I'm working on the way trees generate, and one approach I'm considering involves each tree having an associated tickable tileentity. In it's generated state, the only thing the update does is check a boolean property in the blockstate at its position and then return (the condition will only be true after the player interacts with the tree in some way). Will this simple check, but executed every tick for every tree, have a significant impact on performance? The other alternative is to have two different blocks which look and function the same except for tileentities - generate the one that has no tileentity, and turn it into the one with a tileentity when it's needed. But that would mean duplicating things and would be kind of confusing and illogical. I just don't really know how to judge the performance effects of things like this, so if anyone has input I'm all ears.

[Jay Avery]

15 minutes ago, diesieben07 said:

You can have a TileEntity based on the block state. You don't need two blocks, you can just return false from hasTileEntity for block states that should not have a TE.

 Ohh, thanks. So if I do that, then the TE will be created when the blockstate changes to the TE-requiring state, and removed when it changes back? Do I need to do anything manually to make sure it happens correctly?