[
https://issues.apache.org/jira/browse/LOG4J2-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651812#comment-16651812
]
ASF GitHub Bot commented on LOG4J2-2475:
----------------------------------------
Github user cakofony commented on the issue:
https://github.com/apache/logging-log4j2/pull/218
In most cases, I don't think this will make much difference because setting
all 10 spots in a the reusable parameter buffer is incredibly fast.
This aims to solve problems that arise when a larger parameter array is
passed to a logger, since that array will be reused and passed between
MutableLogEvent (or RingBufferLogEvent) and ReusableParameterizedMessage. I
don't want to discard parameter arrays above a given threshold because there
are scenarios where we would want to allow them to be reused, but we also don't
want to iterate over each index and set it to null if we know there's only a
single parameter.
I've put together a simple benchmark to illustrate performance
implications. It's fairly contrived, close to the worst case scenario.
Without this change:
```
Benchmark Mode Cnt Score Error
Units
ManyParametersInSetupBenchmark.fewParameters thrpt 3 1706.636 ± 89.416
ops/s
```
With this change:
```
Benchmark Mode Cnt Score
Error Units
ManyParametersInSetupBenchmark.fewParameters thrpt 3 5472588.826 ±
1029286.946 ops/s
```
> Limit reusable event.clear parameter clearing to argsCount
> ----------------------------------------------------------
>
> Key: LOG4J2-2475
> URL: https://issues.apache.org/jira/browse/LOG4J2-2475
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
>
> Larger parameter arrays may make their way into log4j when passed into the
> logger directly. These may take longer to clear, despite only containing one
> or two parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
