> I started looking into it but got sidetracked
No worries, I've had more time than usual this week to work on side
projects. Please don't feel obligated to respond quickly.
On Thu, Aug 9, 2018 at 2:15 PM Ralph Goers wrote:
>
> Looking at your latest commit, your number looks similar to mine.
>
Looking at your latest commit, your number looks similar to mine.
Ralph
> On Aug 9, 2018, at 11:14 AM, Ralph Goers wrote:
>
> No, I haven’t committed it. I started looking into it but got sidetracked
> with having to earn a living.
>
> Ralph
>
>> On Aug 9, 2018, at 11:13 AM, Carter Kozak
No, I haven’t committed it. I started looking into it but got sidetracked with
having to earn a living.
Ralph
> On Aug 9, 2018, at 11:13 AM, Carter Kozak wrote:
>
> I've pushed the benchmark here:
> https://github.com/apache/logging-log4j2/pull/209
>
> Is the extended stack trace benchmark
I created a micro benchmark for the extended stack trace. It isn’t pretty.
Ralph
> On Aug 9, 2018, at 10:53 AM, Carter Kozak wrote:
>
> That's true, as long as we collect the stack trace when the
> ThrowableProxy is created, the rest can be deferred. I can take a look
> at this.
>
> I'm
That's true, as long as we collect the stack trace when the
ThrowableProxy is created, the rest can be deferred. I can take a look
at this.
I'm working on a benchmark with a larger stack to simulate conditions
in a real application as well.
-ck
On Thu, Aug 9, 2018 at 12:47 PM, Ralph Goers
What I don’t understand is that ThrowableProxy seems to be doing a whole bunch
of stuff in the constructor. I would think a lot of that could be deferred
until the Throwable is being rendered.
Ralph
> On Aug 9, 2018, at 8:10 AM, Carter Kozak wrote:
>
> The piece I'd like to avoid is
The piece I'd like to avoid is ThrowableProxy.loadClass invocations,
which can be expensive depending on the ClassLoader implementation.
The ThrowablePatternConverter implementations all fall back to the
default implementation which operates directly on a Throwable rather
than the proxy object.
I
