Patch to Throwable and StackTraceElement (reduced CPU usage)

[Mike Skells]

Hi Patrick, David,

David - I tried your suggestions, and I agree it must be faster, but it is in the noise of my test env. not very satisfactory ....

Patrick - Unfortunately Appendable doesn't provide all of the interface that you need. All of the methods throw IOException and you cannot append an int (for the line number)

I did follow part of the same route as you suggested though to let
1. the WrappedPrintWriter extend AbstractStringBuffer,
2. write an optimised character buffer that is specific to the needs (overly optimised) 

in the first case it was slightly slower, and in the second much slower, 
I suspect that my testing regime is (A) not valid or (B) I am falling foul of some optimisation in the system classes or the JIT that is not visible at the java level ... (C) maybe I am missing the obvious though.

I enclose an updated Throwable (as per 2) in case (C) if true and you can point out the error of my ways ....

Regards

Mike



>________________________________
>From: Patrick Reinhart <patrick at reini.net>
>To: Mike Skells <mike.skells at talk21.com>
>Cc: David Holmes <david.holmes at oracle.com>; "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
>Sent: Wednesday, 12 October 2011, 9:28
>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage)
>
>
>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
>> 
>
>
>
>
>