[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961199#comment-13961199
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
So, are you saying that the only benefit is that I am guaranteed that some
relationships cannot be modified? That seems like it would add complexity if
some relationships can be modified and not others. Why can't I just make sure
my client code never modifies those relationships?
I went ahead and tried the volatile immutable arrays, and it definitely helps.
Here's my results:
||Depth||Current||Concept worst||Concept average
| 3 | 340K ops/ms | 280K ops/ms (17% slower) | 380K ops/ms (12% faster)
| 2 | 680K ops/ms | 360K ops/ms (47% slower) | 430K ops/ms (36% slower)
| 1 | 1230K ops/ms | 500K ops/ms (60% slower) | same as worst
| 0 | 2550K ops/ms | 2000K ops/ms (21% slower) | same as worst
The difference between "Concept Worst" and "Concept Average" is because it
might not take x number of checks for a parent that is x levels away. On
average, it would take only x/2 checks since all parent names are merged
together for testing purposes. As you can see, the average case is already
faster now at 3 levels deep. I don't think there is any way to get the 0 and 1
level deep tests to be faster than what we have currently as the current
implementation simply needs to check one or two variables, rather than
iterating over an array.
But in the end, we're talking about hundreds of millions of {{isInstanceOf}}
invocations per second. This marker test is only one small part of the entire
logging performance picture. And it is only going to cause a small (and I think
very small) penalty for those who even use the markers.
The benefit is a more flexible marker hierarchy and full support for slf4j.
> Markers not as powerful as slf4j
> --------------------------------
>
> Key: LOG4J2-585
> URL: https://issues.apache.org/jira/browse/LOG4J2-585
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.0-rc1
> Reporter: Bruce Brouwer
> Attachments: ConceptMarkerBenchmark.java,
> CurrentMarkerBenchmark.java, log4j2-585-concept.patch
>
>
> Log4J's markers are not as flexible as markers in SLF4J.
> First, SLF4J's markers are mutable. By allowing markers to be mutable, I can
> change the relationship of markers to each other based upon runtime or
> business conditions.
> Second, and more importantly I think, is that essentially SLF4J markers have
> this parent/child relationship, much like Log4J, except that in SLF4J, I can
> essentially have a marker with multiple parents. For example, I might want
> this structure:
> * Animal
> ** Bird
> *** Duck
> ** Mammal
> *** Bear
> *** Dolphin
> * Travels by
> ** Water
> *** Duck
> *** Dolphin
> ** Land
> *** Duck
> *** Bear
> ** Air
> *** Duck
> Of course, this is a contrived example, but I wanted to describe the
> relationships. Now, if I wanted to filter based on markers that travel by
> Water for some appenders, and another appender wants to filter by Mammals, I
> can't simply use the single marker of Dolphin.
> Either we need to reverse the marker relationship so that it contains its
> children, much like SLF4J, or we allow markers to have multiple parents,
> which I prefer because it could make it more succinct to define:
> {code}
> private static final Marker BY_LAND = MarkerManager.getMarker("BY_LAND");
> private static final Marker BY_WATER = MarkerManager.getMarker("BY_WATER");
> private static final Marker DUCK = MarkerManager.getMarker("DUCK", BY_LAND,
> BY_WATER);
> {code}
> As for the Marker API, we would either need to change getParent to
> getParents, or get rid of the getParent method from the API and just rely on
> the isInstanceOf method to handle checking multiple parents by looking at
> private member variables (my preference)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
