Re: Location performance

Yes, that was a very interesting read and describes very well how JMH works. Ralph > On Jul 7, 2019, at 4:30 AM, Remko Popma wrote: > > This may be of interest: > https://www.researchgate.net/publication/333825812_What's_Wrong_With_My_Benchmark_Results_Studying_Bad_Practices_in_JMH_Benchmarks

Re: Location performance

This may be of interest: https://www.researchgate.net/publication/333825812_What's_Wrong_With_My_Benchmark_Results_Studying_Bad_Practices_in_JMH_Benchmarks > On Jul 6, 2019, at 5:49, Raman Gupta wrote: > > I'm no JMH expert... but, there is a lot more going on there than just > iterations to

Re: Location performance

I'm no JMH expert... but, there is a lot more going on there than just iterations to avoid the extra time for JIT compilation on warmup. Checkout https://shipilev.net/talks/devoxx-Nov2013-benchmarking.pdf for an idea of the kinds of problems naive timer-only benchmarks encounter, and the different

Re: Location performance

Actually, I would disagree. First, I don’t think the first thousand or slow iterations running slow would matter much with 1.5 million iterations. Lets say the first thousand take 10 times longer the the rest of the iterations. That is still only the equivalent of 10,000 iterations. That is a

Re: Location performance

What I mean is that JMH is written to avoid including behind-the-scenes variability of the code execution that changes from startup until the code has been compiled to native code, garbage collection, synchronization points for threads (safe points), etc. All these things become variable noise

Re: Location performance

Well, I can infer it from the examples but it doesn’t come close to explaining some of the things we use it for. I would argue that logging a line whose value changes on every call, even if it is just an incremented integer, that writes to a file is more than a micro-benchmark, and I truly want

Re: Location performance

The JMH samples (https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/) are the best place to learn about the pitfalls of java micro benchmarks and how JMH can help you avoid them. Remko. (Shameless plug) Every java main() method deserves

Re: Location performance

I don’t understand what you mean with you last message. I don’t really know the details of how JMH works but my understanding is it does something to prevent things like dead code elimination. I haven’t been able to find anything very specific about what JMH actually does though. Ralph > On

Re: Location performance

And the checkpoint bias thing is alleviated amongst other noise from the JVM that would otherwise invalidate the time measurements. On Thu, Jul 4, 2019 at 13:14, Matt Sicker wrote: > I thought JMH ran your code enough for JIT to take effect (though that’s > also up to your warmup iteration

Re: Location performance

I thought JMH ran your code enough for JIT to take effect (though that’s also up to your warmup iteration setting), and the On Thu, Jul 4, 2019 at 00:21, Ralph Goers wrote: > That said, here are the results of the FileAppenderWithLocationBenchmark > from master. > > Benchmark

Re: Location performance

That said, here are the results of the FileAppenderWithLocationBenchmark from master. Benchmark Mode Cnt Score Error Units FileAppenderWithLocationBenchmark.log4j1File thrpt 20 27597.034 ± 350.465 ops/s

Re: Location performance

Remko, I ran the existing JHM benchmarks for both no location and with location and there is still a huge difference. The problem is I don’t necessarily believe the results. Nor do I think the benchmark I have been using is totally accurate either. The problem is that, as I understand it, JMH

Re: Location performance

Well, I just noticed that GcFreeSynchronousLoggingTest is generating a bunch of errors. It seems some of the patterns in gcFreeLogging.xml have location info in the patterns so StackTraceElements are being created. It would probably be simpler to honor the flag then try to reconcile the

Re: Location performance

Never answer email from the phone. It spell checks everything wrong. Ralph > On Jul 2, 2019, at 3:54 PM, Ralph Goers wrote: > > I am using these because the reporter provided them. I will convert them to > John at some point. > > Log4J 3.0 is the master branch. Since it uses java 8 some

Re: Location performance

I am using these because the reporter provided them. I will convert them to John at some point. Log4J 3.0 is the master branch. Since it uses java 8 some things are easier to do than on release-2.x. The withLocation test uses the new builder I add to the api. The witHLocation method doesn’t

Re: Location performance

If memory serves correctly, the `includeLocation` was introduced because it was necessary for async loggers (and it seemed not feasible to get this information from the layout pattern). Async loggers need to know upfront whether they need to pass location information to the consumer thread.

Re: Location performance

But what do you think about includeLocation. Should it override the result of requiresLocation or should the fact that we determined location information is required override the includeLocation setting? Ralph > On Jul 2, 2019, at 2:34 PM, Matt Sicker wrote: > > These benchmarks are

Re: Location performance

These benchmarks are impressive! Moving the point of call site calculation is a great idea. On Tue, 2 Jul 2019 at 16:22, Ralph Goers wrote: > I have made changes to the code the master branch to measure and improve > performance. I have committed some of the changes but not the last set. I >

Location performance

I have made changes to the code the master branch to measure and improve performance. I have committed some of the changes but not the last set. I have not made the latest changes to release-2.x because they will have to be implemented a bit differently to avoid compatibility issues. The table

Re: Location performance

Here's a link to May's discussions in threaded format: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/thread.html#start The discussion is under subject: "Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed" But here's a shortcut: The discussion

Re: Location performance

There seem to be a lot of openjdk mailing lists. I can't find it. Which one is this? (What was the Subject line of the discussion with Mandy Chung?) Sent from my iPhone > On 2016/05/12, at 2:06, Ralph Goers wrote: > > For those you not following the OpenJDK

Re: Location performance

Plus, as you may have noticed, poor API design choices in the JDK live forever because they never remove deprecated code. ;) On 12 May 2016 at 07:55, Mikael Ståldal wrote: > Ah, OK, that makes sense. > > On Thu, May 12, 2016 at 2:50 PM, Ralph Goers

Re: Location performance

Ah, OK, that makes sense. On Thu, May 12, 2016 at 2:50 PM, Ralph Goers wrote: > Yes. Right now we have a chance to get a fix if one is required. > > Ralph > > On May 12, 2016, at 12:58 AM, Mikael Ståldal > wrote: > > Do we really have to

Re: Location performance

Yes. Right now we have a chance to get a fix if one is required. Ralph > On May 12, 2016, at 12:58 AM, Mikael Ståldal > wrote: > > Do we really have to worry so much about this now since Java 9 won't be > released until 10 months or so? > >> On Thu, May 12, 2016

Re: Location performance

Do we really have to worry so much about this now since Java 9 won't be released until 10 months or so? On Thu, May 12, 2016 at 7:52 AM, Ralph Goers wrote: > I need to test it. Walking the Throwable is much slower in Java 9. They > suggest using the StackWalker API,

Re: Location performance

I need to test it. Walking the Throwable is much slower in Java 9. They suggest using the StackWalker API, but walking it from the bottom as we do isn’t very efficient. Instead, they recommend doing walker.walk(s -> s.skip(2).findFirst()); from the class called by the caller (i.e. -

Re: Location performance

Oh, that's new to me. That doesn't sound good... Why is this necessary? Sent from my iPhone > On 2016/05/12, at 8:43, Ralph Goers wrote: > > It would be different. We would be getting the location info in > AbstractLogger in every API method. You wouldn't be able

Re: Location performance

It would be different. We would be getting the location info in AbstractLogger in every API method. You wouldn't be able to delay it until it is requested/required. Ralph > On May 11, 2016, at 3:21 PM, Remko Popma wrote: > > The current way to get location information

Re: Location performance

The current way to get location information is not garbage-free either, so this is not a problem. Have you tried benchmarking this? I'm very curious! Sent from my iPhone > On 2016/05/12, at 2:06, Ralph Goers wrote: > > For those you not following the OpenJDK

Re: Location performance

Oh neat, I didn't know about that feature. On 11 May 2016 at 13:24, Paul Benedict wrote: > Matt, you can take advantage of the new Multi-Release Jar feature of JDK 9: > http://openjdk.java.net/jeps/238 > > This way you can provide a single artifact and have key classes

Re: Location performance

Matt, you can take advantage of the new Multi-Release Jar feature of JDK 9: http://openjdk.java.net/jeps/238 This way you can provide a single artifact and have key classes replaced for JDK 9 with your specialized implementation. Cheers, Paul On Wed, May 11, 2016 at 1:10 PM, Matt Sicker

Re: Location performance

How would we do that while still making log4j compatible with 1.7 and 1.8? On 11 May 2016 at 12:06, Ralph Goers wrote: > For those you not following the OpenJDK mailing list, Mandy is > recommending we do > > walker.walk(s -> s.skip(2).findFirst()); > > in every

Re: Location performance

For those you not following the OpenJDK mailing list, Mandy is recommending we do walker.walk(s -> s.skip(2).findFirst()); in every logger method to capture the stack frame information. We might have to call it twice to get the Class as well. This will probably break the garbage free tests

Re: Location performance

We don’t use that for getting the caller location. We only use the throwable. You are thinking of the code that needs to get the caller’s Class object. Ralph > On May 10, 2016, at 10:33 AM, Matt Sicker wrote: > > JDK 9 should be blocking the sun.reflect classes which means

Re: Location performance

JDK 9 should be blocking the sun.reflect classes which means we fall back to SecurityManager or Throwable depending on the method. On 10 May 2016 at 11:51, Ralph Goers wrote: > I just responded to that thread with the results below. I was hoping we > wouldn’t need

Re: Location performance

I just responded to that thread with the results below. I was hoping we wouldn’t need to use the StackWalker API. Now I am wondering if it is any faster. My initial tests showed it was much faster than using the Throwable, but that doesn’t mean much if that is now slower. Ralph > On May 10,

Re: Location performance

No. On the openjdk list Mandy said that walking the Throwable as we are doing should be faster due to improvements made in JDK-8150778. Ralph > On May 10, 2016, at 9:21 AM, Paul Benedict wrote: > > Are you using the new JDK 9 APIs to walk the stack? > > Cheers, > Paul >

Re: Location performance

That _does_ look worse but I think Paul is right and there is a separate API we need to use: http://openjdk.java.net/jeps/259 On Wed, May 11, 2016 at 1:21 AM, Paul Benedict wrote: > Are you using the new JDK 9 APIs to walk the stack? > > Cheers, > Paul > > On Tue, May 10,

Re: Location performance

Are you using the new JDK 9 APIs to walk the stack? Cheers, Paul On Tue, May 10, 2016 at 11:20 AM, Ralph Goers wrote: > Supposedly Java 9 was supposed to improve the performance of walking the > stack trace. However, the numbers I get below indicate to me that they