TFC, The Fuck U Doin?

TFC, THE FUCK U DOIN?

Ever profiled worldgen only to realize that 50% of the time is taken by TFC’s ore generation and, out of all things, LEAF DECAY?

Ever profiled iterating the recipe registry to find that more than half the time is spent gathering’s TFC capabilities?

Oh, you didn’t… Well, I did, and I then wondered “TFC, what the fuck are you doing?”

It doesn’t do anything good.

Capabilities

TFC’s capability use a Map<Predicate<ItemStack>, Supplier<ICapabilityProvider>> that is linearly iterated on capability gathering.

This means that every single time an ItemStack is created (very often), it tries every single entry, one at a time, to see if it matches the ingredient.
On any relatively large modpack, this is very slow.

This mod fixed this by using a Map<Item, Map<Predicate<ItemStack>, Supplier<ICapabilityProvider>>>, then iterating the matches with the item linearly. This is not API-breaking (the public field is still the same and still contains the items)

Ore Generation

TFC’s ore generation is very slow and quite wasteful. Every vein has, on average, 6 nodes, and the chance for an ore block to generate is inversely proportional to the distance to the closest one. Every block is evaluated independantly, and every distance to every node is checked. This means a lot of distance checks.

TFCTFUD replaces this algorithm with one that starts at the nodes and expand outwards. This way, it can reduce the distance checks by ≈ half. It can also precompute parts of the distance check and reuse them (Δx², notably), further reducing the performance hit.

Loose rocks generation

TFC’s loose rock generation places a placed item TileEntity before checking if there’s actually an item to be placed there. If loose rocks are disabled, it will therefore spawn a TileEntity with an empty item.

TFCTFUD makes it choose the item before placing the TileEntity, and skip the placement if no item is selected, thus making it not place empty placed item.

Entity Worldgen

TFC’s entity worldgen (entities present at worldgen, typically animals on the ground) loops through all registered entities, creating a new instance of each for each chunk. That instance only serves to get the chance for this entity to generate for this chunk. This process can take ≈ 5% of worldgen time in some packs.

TFCTFUD makes TFC reuse the entity instances from chunk to chunk, bypassing the expensive entity creation entirely.

Leaf decay

TFC’s leaf decay algorithm uses a breath-first search with a HashSet<BlockPos> as a cache to remember which nodes have been visited. This means that there is a lot of object allocations (as each BlockPos must be unique) and the BlockPos must be hashed on every access.

TFCTFUD optimized this by replacing the HashSet with a simple boolean[] and computing the index based on the relative coordinate. It is easier in RAM, object allocation and CPU time.

Falling Block

TFC’s falling block manager contains a HashMap<IBlockState, Specification> to associate the blockstates to their specifications. Every single block update, it checks in this HashMap the specification for the block triggering the block update and all of its neighbours. Every single lookup requires iterating though all properties the IBlockState has registered and hashing them. Considering block updates are very frequent, the cost of this adds up fast.

TFCTFUD replaces this map with a HashMap<Block, Map<IBlockState, Specification>>, where the internal map is iterated linearly (and it really just two lists). There is also a fast path for blocks whose blockstates are all registered, skipping the internal map entirely. The cost of looking up a Block key is negligible.

Chunk Generation

TFC’s chunk generation has approximately 7000 calls of the form random.nextGaussian() < threshold per chunk. random.nextGaussian() is relatively slow, and this call alone can take 1/8 of worldgen time.

TFCTFUD replaces these calls by precomputing the probability of this call being true once per chunk, then using calls of the form random.nextFloat() < probability. In the best case (for Gaussian), random.nextFloat is at least 4x faster.

Misc

• Option to remove calendar logging as it is quite spammy and not useful
• Option to use a translationkey instead of hardcoded strings for the item size
• Option to have TFC’s JEI plugin knapping only show one stone type, cutting down on clutter
• Configurable rotting overlay blacklist as it is undesirable for some immediately-rotting and/or modded items