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
>
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 a
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
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 bl
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 that
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
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 http:
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 Ju
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 setti
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
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
FileAppenderWithLocationBenchmark
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 l
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 issues.
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 thing
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 hav
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.
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 impressiv
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
> hav
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 b
19 matches
Mail list logo