grails-profiles / base

2 stars 12 forks source link

Grails app should auto import spring component #97

Closed rainboyan closed 2 years ago

rainboyan commented 2 years ago

Fixed issue: https://github.com/grails/grails-core/issues/12389

osscontributor commented 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.

rainboyan commented 2 years ago

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 )
osscontributor commented 2 years ago

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?

rainboyan commented 2 years ago

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.

osscontributor commented 2 years ago

I will spend more time to figure out why grails nead more than 10s time when scanning component.

Awesome. Thank you!

rainboyan commented 2 years ago

I created a custom Grails profile web-clean, this will meet some of my needs. I'll post some of the research details on Grails performance and optimizations and discuss them with you. Many thanks for your kind and warm help @jeffbrown