Algebraic Data Type Performance Problems

Thanks so much for this project. It's the best way I've found to analyze nullability of Java!

When using an algebraic data type pattern, checker performance degrades as the number of cases within the algebraic data type increases. I haven't let checker run long enough to complete the either5 or higher or emptyeither6 or higher cases.

An example project is available at https://github.com/hborders/checker-perf

$ ./gradlew :emptyeither2:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 4s

$ ./gradlew :either2:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 5s

$ ./gradlew :emptyeither3:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 8s

$ ./gradlew :either3:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 16s

$ ./gradlew :emptyeither4:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 47s

$ ./gradlew :either4:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 2m 20s

$ ./gradlew :emptyeither5:assemble -DrocksSkipCheckerFramework=false
Configuration on demand is an incubating feature.

BUILD SUCCESSFUL in 8m 17s

Start with the linked checker-perf project and run the provided Gradle assemble commands for the either and emptyeither cases. Compare checker timings as the number of algebraic-data-type cases increases, including the cases that complete. Done means the performance degradation is addressed and the reproduced builds complete without the reported escalation.