wasyl
05/16/2021, 12:19 PMdetectConfig()
. Disabling jar scanning for it is not reasonable, because jars may provide listeners.
So while config discovery is pretty useful, would you consider some other mechanism for that? I know that scanning can be disabled, but then modules wouldn’t be able to provide useful listeners (I think I even requested discovery at one point, to avoid having to declare a merged project config in each module). One thing that comes to mind is allowing everything that can be AutoScanned now to be provided via ServiceLoaders. Locally I just hardcoded our listeners and got that peak memory down from 4GB to 1GB.
Bottom line: ClassGraph has significant memory impact, at least with larger projects. It’d be nice to have a way to completely bypass it. Btw in addition to memory usage, it also spawns several threads (in my case 18!) that it never releases.sam
05/16/2021, 3:00 PMwasyl
05/16/2021, 3:15 PMsam
05/16/2021, 3:16 PMwasyl
05/16/2021, 3:19 PMsam
05/16/2021, 3:20 PMwasyl
05/16/2021, 3:21 PMsam
05/16/2021, 3:21 PMwasyl
05/16/2021, 3:21 PMIf we limit scanning to classes only it should workWe also have listeners in other modules, and the case for scanning was to allow modules to contribute listeners just by adding a dependency on them
sam
05/16/2021, 3:22 PMwasyl
05/16/2021, 3:22 PMsam
05/16/2021, 3:22 PMwasyl
05/16/2021, 3:23 PMsam
05/16/2021, 3:23 PMwasyl
05/16/2021, 3:24 PMacceptPackages
argument?sam
05/16/2021, 3:26 PMwasyl
05/16/2021, 3:28 PMsam
05/16/2021, 3:28 PMwasyl
05/16/2021, 3:29 PMsam
05/16/2021, 3:29 PMwasyl
05/16/2021, 3:29 PMsam
05/16/2021, 3:30 PMwasyl
05/16/2021, 7:33 PMI’ll push a change to close down the classgraph threads at leastThat’s my bad, the threads are closed right after scanning, the missing
scanResult.close()
in detektConfig.kt
is just to clean up some files. I looked at the profiler wrongsam
05/16/2021, 8:05 PM