Improved access speed of isPossibleType by bbakerman · Pull Request #4040 · graphql-java/graphql-java
This builds on #4033 but it creates a cache in the ImmutableTypeRegistry so that we don't need to iterate all types on each call
@xuorig - This takes your PR and extends it more to have a reverse cache of interface -> implementing type def AND it uses your cheaper TypeInfo method in more places
This means that algo change you made in your PR is not really needed. Why? Because when we are in read only mode, we don't have to loop all types to find all implemeenting types of an interface, we did that once at build time for all interfaces. So later the type checking will be faster
I originally had a cache of interface to implementing types but it turns out its slower to eagerly build this cache than it is to run the code that used it so I brought @xuorig changes into this PR
So in benchmark terms
c7495f921d2bd10afcb4db4616817a4c67de5ddb - master back before we started @xuorig changes
Benchmark Mode Cnt Score Error Units
CreateExtendedSchemaBenchmark.benchmarkLargeSchemaCreate thrpt 9 4.979 ± 1.058 ops/min
CreateExtendedSchemaBenchmark.benchmarkLargeSchemaCreateAvgTime avgt 9 11205.547 ± 1306.952 ms/op
This PR
Benchmark Mode Cnt Score Error Units
CreateExtendedSchemaBenchmark.benchmarkLargeSchemaCreate thrpt 9 46.436 ± 2.512 ops/min
CreateExtendedSchemaBenchmark.benchmarkLargeSchemaCreateAvgTime avgt 9 1250.350 ± 26.185 ms/op
master without this PR
Benchmark Mode Cnt Score Error Units
CreateExtendedSchemaBenchmark.benchmarkLargeSchemaCreate thrpt 9 45.801 ± 2.211 ops/min
CreateExtendedSchemaBenchmark.benchmarkLargeSchemaCreateAvgTime avgt 9 1253.292 ± 58.405 ms/op
So overall things have gotten significantly faster in building large schemas with lots of interfaces and extends. in fact since @xuorig started his investigations and inspired changes, we are 10x faster on this benchmark
This PR does not add much more raw throughput BUT it will reduce memory used