[WIP|1.7.10] FastCraft 1.25 (Note: All Posts of new Members need to be approved first, so if you press the submit button but no new post appears here, it is in the folder of posts to be approved first, and Player will receive them a few hours later)

  • Hey Player, I recently discovered a performance issue in Minecraft 1.7.10 that occurs when Flaxbeard's Steam Power and GregTech are installed together. Currently, certain code within FSP makes liberal use of net.minecraft.world.World#getTileEntity(). Apparently the way Mojang has coded it, all loaded tile entities are stored in a big list and getTileEntity( x, y, z ) performs a linear search over this list to locate the tile entity at these coordinates. In the worst case, there is no tile entity at these coordinates and the entire list is searched twice. This isn't a big deal when the number of tile entities is small, but GregTech uses TileEntities for its ores and there can be thousands across loaded chunks at any given time. When you put these three things together a major performance issue results.

    This is looking more and more like a general performance issue that will occur any time there are a lot of tile entities and a lot of calls to getTileEntity() being made. That being said, do you think a future version of FastCraft could optimize the implementation of getTileEntity() somehow?

  • The linear search/list is only for pending tile entities. Pending TEs are TEs that were created while processing another TE until they get flushed to the regular data structures the next tick. Due to the very temporary nature the list is usually empty and otherwise small. TE queries mostly happens via getChunkFromChunkCoords(...).func_150806_e(...) in the middle of getTileEntity(...).

    There may be corner cases where the list intermittently grows to a significant size, but I don't remember having seen anything severe enough to warrant a targeted tweak.

    The O(1) map lookups involved in fetching a chunk+te are usually the real problem. Mods with lots of neighbor interaction employ caches to limit the impact, the regular lookup is already optimized by Fastcraft. I however can't/don't want to add local caches to arbitrary mods. TileEntitySteamHeater could check its heaters only every n ticks, which is more powerful than anything I can do in a generic way.

  • I see, thank you for the insight and sorry to bother you. The profiler I was using indicated that Minecraft was spending a lot of time in getTileEntity() but not a whole lot of time in func_150806_e, so I jumped to conclusions and assumed that meant the list stored all loaded tile entities. I'll do some debugging later to try and get a better idea of what's causing the problem.