| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
I wonder if using LambdaMetafactory would provide similar speedup vs. Method reflection but with vastly simpler implementation. Some blogs & benchmarks indicate that it's almost as fast as direct access: |
Sorry, something went wrong.
…y certain properties and can indicate which ones
|
I am using reflectasm for our internal graphql implementation I think you can try this one too |
Sorry, something went wrong.
|
FWIW, In my expirience, both Javassist and Reflectasm have problems with JDK 17+ support. The only known to me code-generation library usable on newest JVMs is ByteBuddy (https://github.com/raphw/byte-buddy). Both Hibernate and Spring moved to using ByteBuddy, so it's a safe choice. |
Sorry, something went wrong.
Sorry, something went wrong.
|
We wont be using byte code generation - its price is too high for the pay off |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This PR is was inspired from some work done on https://github.com/jord1e/graphql-java-asm-datafetcher
While it does not use any of the code, it uses the some of the idea.
That is could you dynamically generate a class that helps you fetch directly via method calls instead of reflection Method.invoke() calls
This uses JavaAssist to generate a peer class for each source class.
The generated class looks much like this
public class GeneratedUniqueName implements ByteCodeFetcher { public Object fetch(Object sourceObject, String propertyName) { if (sourceObject == null) { return null; } graphql.schema.bytecode.SettersAndVoidPojo source = (graphql.schema.bytecode.SettersAndVoidPojo) sourceObject; if("name".equals(propertyName)) { return source.getName(); } else { return null; } } }Calling a method directly is 1.7 times after than use the same method.invoke. That sounds like a lot however its very quick so in the schema of all graphql processing its not a lot.
However we do get some improvements in object heavy benchmarks like the introspection one
vs master
This needs a few things to be ready.
We would need to shade Java assist - we dont want to expose this out to others.
We need a JVM wide switch to turn this on or off. Like the graphql.schema.PropertyDataFetcherHelper#setUseSetAccessible flag we have today.
I think we might turn if off in a release and let people opt in and then maybe invert that on another release.