A DESCRIPTION OF THE REQUEST :
My application has moderately intensive logging (about 5 log lines per second), and the logging code uses Throwable.printStackTrace to determine the line number in the code.
When profiling the application, and profiling the logging in particular, the biggest bottleneck is in in the printStackTrace method, specifically on line 657:
s.println( " \tat " + traceElement);
This is using CPU and memory to concat the string, when it could be done as two method calls:
s.print( " \tat " );
s.println(traceElement);
Obviously it could be argued that this is just pushing the concatenation down to the PrintStreamOrWriter s, however this is implemented differently and doesn't involve the construction of a temporary StringBuilder as the current code does.
Furthermore, the traceElement String length is usually greater than the default StringBuilder size of 16, so an array growth is being performed to expand the StringBuilder size, and a copy of the old array into the new one, which again would be unnecessary with the two-line solution above. This is a needless waste of resources, albeit minor.
JUSTIFICATION :
This enhancement is a minor optimization to avoid unnecessary object creation, and also avoids needless array copies. It is a very simple fix, modifying just a single line of code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No temporary StringBuilder should be constructed in the printStackTrace method.
ACTUAL -
StringBuilders are created and often expanded in capacity, in the printStackTrace method.
My application has moderately intensive logging (about 5 log lines per second), and the logging code uses Throwable.printStackTrace to determine the line number in the code.
When profiling the application, and profiling the logging in particular, the biggest bottleneck is in in the printStackTrace method, specifically on line 657:
s.println( " \tat " + traceElement);
This is using CPU and memory to concat the string, when it could be done as two method calls:
s.print( " \tat " );
s.println(traceElement);
Obviously it could be argued that this is just pushing the concatenation down to the PrintStreamOrWriter s, however this is implemented differently and doesn't involve the construction of a temporary StringBuilder as the current code does.
Furthermore, the traceElement String length is usually greater than the default StringBuilder size of 16, so an array growth is being performed to expand the StringBuilder size, and a copy of the old array into the new one, which again would be unnecessary with the two-line solution above. This is a needless waste of resources, albeit minor.
JUSTIFICATION :
This enhancement is a minor optimization to avoid unnecessary object creation, and also avoids needless array copies. It is a very simple fix, modifying just a single line of code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No temporary StringBuilder should be constructed in the printStackTrace method.
ACTUAL -
StringBuilders are created and often expanded in capacity, in the printStackTrace method.
- relates to
-
JDK-4059189 Compiler generated code for String.operator+() could avoid allocations.
- Closed
-
JDK-4398094 Request improved code for string concatenation
- Closed