On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad wrote:
> - A small portion (~5%) of the instrumented overhead when spinning MH/LF
> classes in `InvokeBytecodeGenerator` comes from creating the exact same
> `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple
> of constan
On Fri, 6 Sep 2024 10:42:54 GMT, Shaojin Wen wrote:
>> - A small portion (~5%) of the instrumented overhead when spinning MH/LF
>> classes in `InvokeBytecodeGenerator` comes from creating the exact same
>> `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple
>> of consta
On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad wrote:
> - A small portion (~5%) of the instrumented overhead when spinning MH/LF
> classes in `InvokeBytecodeGenerator` comes from creating the exact same
> `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple
> of constan
On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad wrote:
> - A small portion (~5%) of the instrumented overhead when spinning MH/LF
> classes in `InvokeBytecodeGenerator` comes from creating the exact same
> `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple
> of constan
On Fri, 6 Sep 2024 10:01:39 GMT, Claes Redestad wrote:
> - A small portion (~5%) of the instrumented overhead when spinning MH/LF
> classes in `InvokeBytecodeGenerator` comes from creating the exact same
> `RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple
> of constan
- A small portion (~5%) of the instrumented overhead when spinning MH/LF
classes in `InvokeBytecodeGenerator` comes from creating the exact same
`RuntimeVisibleAnnotationsAttribute` for every method. Introducing a couple of
constants has a small but measurable impact.
- `classDesc(MemberName.cla
