Patch to Throwable and StackTraceElement (reduced CPU usage)

[Patrick Reinhart]

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
>