You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the program starts executing the IndyBootstrap#bootstrap method, there will be logic to obtain the class name list of the specified plug-in. However, in this logic, I think some optimizations can be made. As shown in the figure, in the original method, multiple threads may concurrently request the data of the same pluginPackage. At this time, multiple jar packages will be scanned, and there will also be a PackageScanner global lock in it; suppose we advance this lock and based on pluginPackage distinguishes different locks, which can improve application startup performance and reduce memory usage caused by package scanning. I tested it locally and it works.
Describe alternatives you've considered
The text was updated successfully, but these errors were encountered:
Thanks for the input here. We won't have time to advance this proposal in the near future, but will definitely keep the issue open for when time comes available!
Is your feature request related to a problem?
Describe the solution you'd like
When the program starts executing the IndyBootstrap#bootstrap method, there will be logic to obtain the class name list of the specified plug-in. However, in this logic, I think some optimizations can be made. As shown in the figure, in the original method, multiple threads may concurrently request the data of the same pluginPackage. At this time, multiple jar packages will be scanned, and there will also be a PackageScanner global lock in it; suppose we advance this lock and based on pluginPackage distinguishes different locks, which can improve application startup performance and reduce memory usage caused by package scanning. I tested it locally and it works.
Describe alternatives you've considered
The text was updated successfully, but these errors were encountered: