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