Which suggestion? The one about using the provided Class's ClassLoader in LogManager?
On 3 August 2014 02:48, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Yes, ClassLoaderContextSelector isn’t terribly fast. To be honest I made > it the default because I wanted to get feedback on how well it worked or if > it caused issues. I have been pleasantly surprised that there really > haven’t been any serious issues reported on it. > > Over the life of an application though you would only expect thousands of > unique Loggers at the most, so the creation time over the lifetime of the > application probably doesn’t matter much. However, if the application > creates Loggers when classes are created and a lot of them are created at > startup then this could impact startup time significantly. For that reason > I would encourage finding a way to do what Matt is suggesting. I had > actually thought of it myself but just never got around to it. > > Ralph > > On Aug 2, 2014, at 8:05 PM, Remko Popma <remko.po...@gmail.com> wrote: > > 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 <boa...@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 <boa...@gmail.com> >> > > > -- Matt Sicker <boa...@gmail.com>
