Closed rainboyan closed 2 years ago
This change looks like it would enable component scanning by default for newly created apps. Is that the case?
I think component scanning was disabled by default intentionally, for the benefit of runtime performance.
Thank you for your explain, I know performance is very important, but the development experience and velocity of developers also important, spring support component scanning from version 2.5, many developers have already use it to develop libraries and frameworks. In a Spring Boot project, we typically set the main application class with the @SpringBootApplication
annotation. Under the hood, @SpringBootApplication
is a composition of the @Configuration
, @ComponentScan
, and @EnableAutoConfiguration
annotations. Grails based on Spring and Spring Boot, should support this feature by convention, it make us create app and run quickly.
In production, the performance is most important, if the app is very very large then improve it will not be too late, :)
I create a grails demo app, with large number of Spring Beans and Config.
I run the demo app in development and product environment, had collected the result below, I hope we can measure and improve the framework. @ComponentScan
annotation has many config options, such as Filters, Scope, @Qualifier
. Spring framework now support generating an index of candidate components,
While classpath scanning is very fast, it is possible to improve the startup performance of large applications by creating a static list of candidates at compilation time. In this mode, all modules that are targets of component scanning must use this mechanism.
The large demo app and more result data please go to here
Bean & Config | Default(Not Used) ( Production ) | @ComponentScan ( Production ) |
---|---|---|
10 + 10 | 2715ms, 719.5M ( 6595ms, 659.2M ) | 2791ms, 421.5M ( 6783ms, 657.3M ) |
50 + 50 | 2727ms, 722.2M ( 6635ms, 665.2M ) | 2921ms, 661.9M ( 6973ms, 631,6M ) |
100 + 100 | 2734ms, 665.2M ( 6546ms, 617.3M ) | 3137ms, 759.8M ( 7183ms, 722.1M ) |
500 + 500 | 2763ms, 614.0M ( 6776ms, 618.3M ) | 4641ms, 794.4M ( 9658ms, 773,1M ) |
1000 + 1000 | 2848ms, 721.8M ( 7047ms, 713.0M ) | 6282ms, 976.8M ( 12002ms, 928.7M ) |
2000 + 2000 | 3049ms, 745.6M ( 8704ms, 706.0M ) | 9532ms, 1011.7M ( 20637ms, 1.17G ) |
I haven't looked at the code but from reading your comments above and the README at the linked repo, I assume the megabytes are measuring either heap size or how much of the allocated heap is consumed, but it isn't clear what the milliseconds are. is that the time from starting the process to when it is ready to receive a request?
yes, they are startup time and heap usage. I compare to spring boot app with same number of Bean and Config, it used 3598ms. I will spend more time to figure out why grails nead more than 10s time when scanning component.
I will spend more time to figure out why grails nead more than 10s time when scanning component.
Awesome. Thank you!
Fixed issue: https://github.com/grails/grails-core/issues/12389