Performance regression in 3.43.0 with nested streams #6623
Comments
|
Thanks for the detailed report. I agree this is likely related to improvements to type argument inference (#979). We'll try to see if we can speed this up. |
|
I encountered similar problem with reactive streams; it would be great if you are able to somehow tackle this problem even though I understand performance optimisation is always difficult. Problems with faulty inference are reported as warning, thus easy to locate, but finding constructs that cause build to hang takes lots of time - one of our modules that contained code with nested flatMap that normally builds in 2min 30 was killed after 1 hour after upgrade from 3.42.0 to 3.46.0 |
|
@MichalStehlikCz As a workaround, try reducing nested lambda expression by extracting some code into methods. It seems like checkerframework has some sort of combinatorical explosion/time complexity issue with nested lambdas and maybe also multiple parameters. When I experienced this issue originally, I think it was also something like 30min. |
|
When I found the spots, I was able to fix them by specifying explicit type parameter on last inner map / flatMap call.. finding them is what takes time |
When compiling a class with nested streams using the nullness checker of 3.43.0, it is significantly slower than in 3.42.0.
Consider the following source code:
Compiling that with
checker-framework-3.43.0/checker/bin/javac -processor nullness TestClass.javatakes more than one minute "on my machine" while it takes less than two seconds with 3.42.0.This could be related to #979.
Expected output
With 3.42.0, I get the following
$ time ./checker-framework-3.42.0/checker/bin/javac -processor nullness src/main/java/io/github/danthe1st/checkertest/TestClass.java real 0m1,822s user 0m4,671s sys 0m0,257sActual output
With 3.43.0, I get the following
$ time ./checker-framework-3.43.0/checker/bin/javac -processor nullness src/main/java/io/github/danthe1st/checkertest/TestClass.java real 1m24,495s user 1m44,309s sys 0m0,820sWhen I add a fourth parameter to
TargetInner, this takes more than 3 minutes:$ time ./checker-framework-3.43.0/checker/bin/javac -processor nullness src/main/java/io/github/danthe1st/checkertest/TestClass.java real 3m15,223s user 3m43,306s sys 0m1,546sThe issue also occures in 3.44.0.
Reproducer information
I created a full reproducer using GitHub Actions here. You can view the build logs here or here for 4.44.0 (both with Maven and running from the CLI with the Checker Framework wrapper).
With GitHub Actions, compiling this class took
01:53 minwith Maven and1m51.052swithout Maven.System information
I am using
Ubuntu 24.04 LTS x86_64with a6.8.0-31-generickernel.$ java -version java version "21.0.2" 2024-01-16 LTS Java(TM) SE Runtime Environment Oracle GraalVM 21.0.2+13.1 (build 21.0.2+13-LTS-jvmci-23.1-b30) Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 21.0.2+13.1 (build 21.0.2+13-LTS-jvmci-23.1-b30, mixed mode, sharing)Output with diagnostic information
When running with
-version -Aversion -AprintGitProperties -verbose -AprintVerboseGenerics, I get the following output:The text was updated successfully, but these errors were encountered: