@metatype The new FastLogger outperforms the vanilla Log4j Logger and the old 
FastLogger in every way EXCEPT for log statements that are enclosed within 
isDebugEnabled  and isInfoEnabled. Since we don't use isInfoEnabled, we're 
really only concerned about the difference in performance for isDebugEnabled.

Here's the numbers that are concerning:
```
Old FastLogger (rerun)
FastLoggerBenchmark.isDebugEnabledLogStatementWithFastLogger  thrpt       
1699492309.718          ops/s
FastLoggerBenchmark.isDebugEnabledLogStatementWithLogger      thrpt        
569546071.809          ops/s
```
```
New FastLogger (rerun with updated changes)
FastLoggerBenchmark.isDebugEnabledLogStatementWithFastLogger  thrpt       
1614609085.057          ops/s
FastLoggerBenchmark.isDebugEnabledLogStatementWithLogger      thrpt        
554213160.956          ops/s
```
And here's one more run of New FastLogger just to demonstrate variance from 
run-to-run:
```
New FastLogger (rerun again with updated changes)
FastLoggerBenchmark.isDebugEnabledLogStatementWithFastLogger  thrpt       
1647331591.312          ops/s
FastLoggerBenchmark.isDebugEnabledLogStatementWithLogger      thrpt        
577427794.141          ops/s
```
It comes close to old FastLogger but can't quite catch up on this one.

To really be sure, I think I'd have to run the benchmarks for several longer 
iterations (overnight). Then we can be more confident of the numbers we're 
seeing.

I should also point out that wrapping logger.debug statements inside 
isDebugEnabled guard clauses always outperforms logger.debug by itself for 
vanilla Logger, old FastLogger and new FastLogger. So as much as we want to be 
able to remove those guard clauses, I think we may be stuck with them for 
performance reasons.

[ Full content available at: https://github.com/apache/geode/pull/2798 ]
This message was relayed via gitbox.apache.org for 
[email protected]

Reply via email to