Patch to Throwable and StackTraceElement (reduced CPU usage)
Patrick Reinhart
patrick at reini.net
Wed Oct 12 08:28:49 UTC 2011
Hi Mike
Zitat von "David Holmes" <david.holmes at oracle.com>:
>> Patrick - this is why you idea doesn't really provide the answer, there
>> is still a StringBuilder created for each line of stack trace printed,
>> and probably a resize as the line is probably > 16 chars, as well as 2
>> writes for each line
Ups, I missed the toString() part of the StackTraceElement - shame on me :-)
What if you would define a java.lang.Appendable implementation instead of
StringBuilder in your StackStraceElement.appendTo() method. You would then be
able to write the Throwable print stacktrace methods it this way:
for (StackTraceElement traceElement : trace)
s.append("\tat ");
tranceElement.appendTo(s);
s.println();
and Similarly for:
for (int i = 0; i <= m; i++)
s.append(prefix).append("\tat ");
tranceElement.appendTo(trace[i]);
s.println();
In this case you would pass the actual PrintStream/Writer instance instead of
creating new StringBuilders at all and your toString() method using a new
StringBuilder still would work the same way.
Or did I still miss something?
Cheers,
Patrick "Reini" Reinhart
>
> Ah I see. I missed the key point that you now use a single SB across
> the entire process of printing the stacktrace. I guess my only
> additional comment on that is that it would seem to be be a good
> idea to increase the initial size of that single SB as it is likely
> to grow on its very first use.
>
> Also a minor gain might be had to change println(sb) to be
> println(sb.toString()) and avoid the String.valueOf intermediate
> call (and null check).
>
> Aside: can't help but feel that the streams should directly support
> CharSequences so that we don't need to convert to intermediate
> Strings.
>
>
> Cheers,
> David
>
More information about the core-libs-dev
mailing list