Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template methods should be replaced with runtime implemented interfaces #8

Open
bergerkiller opened this issue Jul 7, 2017 · 1 comment

Comments

@bergerkiller
Copy link
Member

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?)
@bergerkiller
Copy link
Member Author

This has been improved by runtime-generating the handles. This means that using the Handle type (not the .T template elements) can have improved performance when invoking methods with primitive parameters or return types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant