Seems ok with me if you have a use case for it, even if it just makes tests
cleaner.
Gary
On Nov 10, 2016 4:55 AM, "Mikael Ståldal" wrote:
> Would it make sense to have a removeAll(Iterable) method in
> ThreadContext, as a companion to putAll(Map)?
>
> And a corresponding method in ThreadContex
[
https://issues.apache.org/jira/browse/LOG4J2-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15697097#comment-15697097
]
Remko Popma commented on LOG4J2-1718:
-
Converted to annotation in commit 3ee7d69.
>
Isn't this code slower? It feels like we are putting memory performance
ahead of speed.
Gary
-- Forwarded message --
From:
Date: Nov 25, 2016 6:05 PM
Subject: logging-log4j2 git commit: LOG4J2-1684 avoid creating temp objects
To:
Cc:
Repository: logging-log4j2
> Updated Branches
No this is actually faster.
I believe I created a benchmark for this that showed that for-each iteration is
slower than indexed iteration.
Sent from my iPhone
> On 26 Nov 2016, at 11:29, Gary Gregory wrote:
>
> Isn't this code slower? It feels like we are putting memory performance ahead
>
But shouldn't the comparison really be using [] access as opposed to
charAt()?
Gary
On Nov 25, 2016 6:41 PM, "Remko Popma" wrote:
> No this is actually faster.
> I believe I created a benchmark for this that showed that for-each
> iteration is slower than indexed iteration.
>
> Sent from my iPh
I guess it depends.
Obtaining the array is not free: it needs to be allocated, then initialized
with zeros (Java lang spec), and finally the String contents are copied into
it.
Once we have an array, accessing its elements directly will be faster than
going through the String wrapper object si
