bergerhealer / mountiplex Goto Github PK

Currently code sections are written out as-is and not generated at runtime. Requested is to add a way to compile these code sections at runtime, so that preprocessor declarations can operate on them. This will enable more efficient (less runtime checks) and compact code.

Right now we use abstract Template methods with various invoke/invokeVA methods. While this works, it incurs a performance drain for methods that use primitives in parameters or return type, or contain Object parameters that can be exposed to save unneeded casting.

Suggested solution: make Template.Class implementations abstract with abstract methods for all to-be-implemented methods. For example:

public static abstract class EntityClass extends Template.Class<EntityHandle> {
    public final Template.Field.Double locX = new Template.Field.Double();
    //etc.

    public abstract int getTeleportTicks();
    public abstract List<Entity> getPassengers();
    public abstract void move(Object moveType, double dx, double dy, double dz);
}

The EntityClass will also include a 'RAW' constant somewhere to declare all raw, unconverted methods. For the raw class itself this variable will be assigned 'this'.

Instead of calling new on this class, it is extended and further implemented at runtime, then assigned to Template.T variable for later use by the Handle or elsewhere.

Ideally this will be implemented ON TOP of the current template system to avoid compatibility issues.

Benefits:

• Performance improvements (less casting, boxing, unboxing, variable access)
• Reduces the amount of classes that are generated at runtime (permgen space)
• Type-safety for method signatures, instead of Object everywhere
• Better API

Problems:

• Complexity of implementation
• Lazy-loading of methods becomes hard or impossible
• Can no longer use methodName.toMethodAccessor() for legacy API
• Can no longer treat methods as objects, which allowed them to be used as method arguments
• Time to implement (is it really needed?)

Right now it will default to using the standard Object get/set function, which will default to using Reflection for all primitive types. This incurs a performance overhead when copying objects, mainly during class interception/hooking.

Performance can be gained enabling the same invoke(a, b, c, d, e) method overloads for public static methods, like is already the case for public member methods.

The output conversion tree is used to chain up converters in optimal routes from all possible input types towards a given output type. The problem is that Input Converters mess this up a little, because they use Object as input type. As a result, I see cases where it lazy-converts and Object to a String and then feeds that into the input converter.

Input converters shouldn't at all be stored in the conversion tree. They should instead be queried for every new input type to populate new converters (getConverter()).

Ex:

class Chunk {
    public final (Set[]) EntitySlice<Entity>[] entitySlices;

    public (BlockData) IBlockData getBlockData((IntVector3) BlockPosition blockposition);
}

In this case, Mountiplex will place import java.util.Set[]; within ChunkHandler.