Less ambitious, less rubbish 1.12 release

[LunNova]

Tasks:

• Split javassist patching implementation into separate project
  • Split non-minecraft code into JavaPatcher
  • Split minecraft-specific code into ModPatcher
• Mixin implementation in nallar/JavaPatcher. Implement Mixins LunNova/JavaPatcher#2
  • Mixin implementation in Mixin First release task list Mixin#1
  • Mixin transformations in ModPatcherGradle
• Improve performance in ModPatcher by avoiding re-transforming Avoid running the same class through transformers twice ModPatcher#10
• Implement old profiling features in separate mod. Packet profiling TickProfiler#22
• Start from scratch, bring in some important features. Avoid feature creep
  • Implement variant system (core/threaded for now, should be extensible)
  • Implement per-world threading
  • Implement deadlock detector
  • async/threaded chunkloading improvements
    • Fix the bloody stupid chunkloading when you world.get with coords an unloaded chunk
    • Chunkloading cache which actually works
  • Entity collision performance fixes
  • Fix FMLCommonHandler.getEffectiveSide -> hardcode as always running on server
  • Avoid slow operations on TE/Entity lists. See TickManager.batchRemove(Tile)Entities
  • Fix poor World.getPersistentChunks performance

[MrVoltz]

Glad to hear you're coming back! I'm still sticking with your 1.5.2 release and fix everything myself :D.

[Vycraftujto]

Wooow welcome back!!! We are so glad your coming whit 1.8 !!!!

[LunNova]

Sorry about the spam when I closed all the issues there.

I've closed all the old issues, as I won't be doing any further work on older MC versions.

[LunNova]

I've added a task list with basic plans for the first preview release. Have I missed any features people depend on?

I want to try to avoid adding too many features. TT ended up with a LOT of feature creep.

For example, in the new version TT will not have its own profiling, as the same features will be in TickProfiler. I'll need to work on improving TickProfiler's profiling features to match what used to be in TT.

[Slind14]

I'm not sure if you see a solution, anyways, the chunk unloading tends to be more intense than the load once the active/ticking tile entities hit +15k in the world. They are all stored in an array list and on chunk unload they are being removed. But to keep in mind, on tick update minecraft is iterating over the list, so other collections don't make sense either.
On servers with +25k active tile ents we have run good with a list set combination.
You gave us the idea about this some time back, not sure if you remember :)
https://gist.github.com/Slind14/da64506db693f060afdd
https://gist.github.com/Slind14/1531aa0d5db944cc61b0

What I could think of would be to run the chunkunloading only every n ticks for all chunks together, so that it only needs to go over the list once instead of for every chunk.

Anyways its all not about multi threading.

Regarding the collision fix, wouldn't make sense to be kept in separated mod, or would you use multithreading for it?

[LunNova]

I'm not sure if you see a solution, anyways, the chunk unloading tends to be more intense than the load once the active/ticking tile entities hit +15k in the world.

Old TT did as few operations as possible against those lists, and batched any additions/removals to them to once per tick using addAll/removeAll, which is much more efficient than separate remove calls. See TickManager.batchRemove(Tile)Entities. Added to task list.

Regarding the collision fix, wouldn't make sense to be kept in separated mod, or would you use multithreading for it?

Fair point. I had this fix in old versions of TT as it's reasonably easy and helps performance a lot. Spigot sort of did the same thing, but not as well/aggressively. It's not really threading related though.

Reopened #107. The name currently isn't representative of what TT aims to do. Performance improvements, some but not all due to threading.

My "NTweaks" mod is mainly a rushed stop-gap measure because I was running a server for a few friends and there were approximately infinite squid spawning, and I couldn't change dimensions more than a few times due to memory leaks. I'm surprised it's been useful for other people. New TT will be using the same style of configurable patching as used there, so any unwanted patches can be turned off.

[Slind14]

Sounds good. My main concern regarding the collosion fix (and entity list batch remove) was that there might be users that don't want or can't use the multi threading part but would like to use this part. Kinda like nTweaks not being part of TT or ModPatcher.

[Slind14]

I thought further about it and believe it would really be better if those non threading related and non critical patches would be in a separated mod. The performance impact of the collision patch and the entity list batch removes are a big improvement on their own. Especially the batch removes as those avoid the annoying lag spikes on base unload.
From my understanding those wouldn't be too difficult to port. Hence they could probably be used way before the major multi threading is production ready and even on 1.7, if a back porting is manageable.

[LunNova]

What about Optifine style core/extra/ultimate (probably got the names wrong) releases?

[Slind14]

Like?

• basic (solid proof patches, very unlikely to interfere with mods)
• extra (production ready patches, could be incompatible with some mods)
• ultimate (experimental patches, likely to interfere with mods)

[LunNova]

Yes, something like that.

• <PlaceHolderName>-core
• <PlaceHolderName>-threaded
• <PlaceHolderName>-experimental

(TickThreading-threaded really doesn't work as a name)

[Slind14]

Do you want something functional (giving an idea of what it does) or creative (no relation, e.g. forge, bukkit, sponge, glowstone).
Functional I could think of PerfOverhaul (performance overhaul). I'm not sure if that is a common word, in my native language it is used in terms of car and machine tuning.