-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve performance for ByteBuddy rules with common intercept #551
Comments
I think we can remove |
@malafeev, if the |
All rules involving unchained re/transformations have been fixed, except:
In order to switch these rules from unchained to chained re/transformation, an option is to implement an abstraction into the rule definition mechanism to "collate" rules intercepting the same class, and create a "compatibility-based routing mechanism" to use the correct rule definition based on the version of the instrumented library in the runtime, thus allowing ByteBuddy to instrument the runtime only once. |
There are several rules in SpecialAgent that intercept the same class, such as the
spring-web-*
rules. These rules share the same intercept so as to allow SpecialAgent to select the correct version of a particular integration for the specific runtime. This works fine, but it costs the runtime a significant reduction in startup performance. The reason is: for ByteBuddy to apply different rules to the same intercept, it must instrument the same intercept in different layers, each on top of the pervious. This means that ByteBuddy cannot apply the intercept rules in one pass, and must do so in as many passes are there are rules for the same intercept. Currently, 68 of the 72 rules in SpecialAgent can be "globally chained" -- i.e. the rules are chained together to be loaded all in one pass. The remaining 5 rules require their own dedicated pass. Therefore, if the first 68 rules load in a time of1
, then the remaining 5 rules require a load time of1
each (a load time of5
total).There are 2 ways to solve this:
spring-web-*
rules in a way that is compatible for all versions of Spring Web, which may be very challenging.The text was updated successfully, but these errors were encountered: