Optimisations

[TheKodeToad]

Probably not a priority at the moment (more of a long term goal), but Loom does not currently contain any optimisations.

If any optimisations are added in the future, adding them to the Loom would make the updates slower, and might not be very vanilla friendly (for example, Paper can sometimes break vanilla farms), so optional optimisations might be better (admins who want a more vanilla experience, or just want to update as quickly as possible could use the unoptimised version of Loom).

[thatgoofydev]

Yes, this is something we have already thought about.

(Keep in mind the things I am currently going to mention are subject to change, since this is indeed not a priority at the moment)

The way we are currently thinking of solving this is to keep Loom as close to vanilla as possible. This means no optimizations at all (this might exclude some server breaking bugs, like seen in 1.16.5)

As for a version with optimizations, we had the idea of a first-party fork of loom that includes optimizations. Whether these could be optional will be looked into at a later moment. (basically what paper is for spigot but first-party maintained)
This version will of course release slower than the base version.

PS:
I really like the idea of having optimizations optional, but maintenance burden will be the main factor in this.
I have two initial ideas for optional optimizations: (both are not ideal)

1. toggle the changes in code => would be really hard for some optimizations
2. choose patches when building the optimized version of loom => easier to implement/maintain but not perfect

[TheKodeToad]

Paper and Spigot just read the configuration at runtime (probably slows down the code). Alternatively, rather than demanding server admins to build Loom themselves, patching the classes every time the server starts based on the configurations (probably using a class loader, or instrumentation). The build-it-yourself method probably wouldn't be too much effort though, as running a server is already fairly technical.

[thatgoofydev]

patching the classes every time the server starts based on the configurations

That would make the start up time significally longer. Which is not ideal when the server crashes for example and needs to start up again.

I feel the idea I proposed about choosing the patches when building loom would be more useful taking the following into consideration:

• Casual users will probably not require a custom build version an can go with the default version.
• Processional/Experienced users would probably have no problem with building a version themselves. It would give them high customization without start up time increase. I think professional users would rather have the (production) server start faster than not having to build a custom version.

(I am in no way saying this is the correct way to implement this functionality, but it is a way I feel would work for most users)

[TheKodeToad]

I agree that it would work for most users, but it might be hard to customise things that can't be toggled.

For example, if ./loom setup read "loom.cfg" and patched the Minecraft sources according to "loom.cfg", if there was an option to choose how many threads were used for async chunks, patch files don't support variables (at least, I don't think they do).

It would also be quite hard to avoid patch conflicts.

[thatgoofydev]

patch files don't support variables (at least, I don't think they do)

They don't, it's not what they were made for.

A better way to handle variables would be to have them located in the servers' configuration files. If the patch is applied these settings will be read by the server to configure necessary values in the code. If the patch is not applied the settings could just be ignored.

[TheKodeToad]

That would probably work. The configurations could contain a way to temporarily disable the optimisations, but more experienced users could skip the checks entirely in "loom.cfg" or "patches.cfg" (or even deleting the patch files).