logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Idea on how to speed up ClassLoaderContextSelector
Date Sun, 03 Aug 2014 03:05:00 GMT
Thanks for bringing it up here first.

I have a question: is this beneficial for envs like OSGi and web apps, or
are you aiming for a general speedup?
Generally I try to optimize the heck out of things that are called all the
time, but usually don't bother with code that is run only once. That said,
if we can cut the startup time in half or so that would be worth doing. So
I guess it depends on how much of a speedup we gain. (Of course, it if
makes the code simpler, it may be worth doing anyway...)

Completely agree that microbenchmarks are very useful to help us make
decisions based on facts instead of intuition.
(One thing I am learning is that it is worth running benchmarks with one
thread as well as multiple threads, and also to run in multiple OS-es if
possible: that thing with System.currentTimeMillis being so much more
expensive under Linux was a big surprise for me.)

On Sun, Aug 3, 2014 at 9:34 AM, Matt Sicker <boards@gmail.com> wrote:

> I tried this idea out and it looked like it worked fine, but I thought I'd
> propose it here first before making any changes. There are a couple methods
> in LogManager that take a Class instead of a String for the logger name. I
> think that the provided class's ClassLoader should be passed along in the
> appropriate parameters from there and not just ignored. That way, when the
> ClassLoaderContextSelector is invoked, it will have a ClassLoader provided
> to it already and can determine the appropriate LoggerContext without
> having to use reflection.
> Now I'd probably want to write a microbenchmark first before really
> considering this idea, but it's not very complicated. However, this is
> really only invoked once per class approximately (provided you store the
> Logger as a static field), and if for some reason the user uses a Class
> that isn't using in the same ClassLoader as the calling Class, then it
> might cause weird issues. Then again, I might expect as a user that calling
> LogManager.getLogger(String.class), for instance, would give me the same
> Logger no matter what ClassLoader was used provided it's all on the same
> JVM.
> Thoughts?
> P.S. I was playing with the microbenchmarks last night and found this to
> be really awesome! I'm going to add some other benchmarks and migrate the
> remaining unit tests we have that are purely for benchmarking purposes into
> the log4j-perf module. There's no need to run performance tests in our unit
> tests when they don't even verify anything about the output!
> --
> Matt Sicker <boards@gmail.com>

View raw message