Log4j Version 1.2.14: Class NewVsSetLen

Log4j 1.2

previous page next page

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

Log4j 1.2.14

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: INNER | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

org.apache.log4j.performance Class NewVsSetLen

java.lang.Object
  |
  +--org.apache.log4j.performance.NewVsSetLen

public class NewVsSetLen
extends Object

This program compares the cost of creating a new StringBuffer and converting it to a String versus keeping the same StringBuffer, setting its size to zero and then converting it to String.

The table below gives some figures.

Performance comparisons of new buffer creation versus setLength(0) approach for various message sizes and secondary loop lengths.
Total Message length	0		1		2		4		8
Total Message length	New Buffer	setLength	New Buffer	setLength	New Buffer	setLength	New Buffer	setLength	New Buffer	setLength
256	33	22	34	22	34	22	34	22	33	23
1024	58	41	59	45	59	48	59	51	60	44
4096	146	132	138	132	144	126	142	132	136	132
16384	617	593	593	609	601	617	601	632	593	632
65536	3218	3281	3093	3125	3125	3156	3125	3281	3062	3562
262144	14750	15125	14000	15500	14000	16125	14000	18000	14000	21375
1048576	87500	80000	60500	82000	57000	93000	57500	118500	57500	168500

The tests copy a message to a destination string buffer and then copy a 256 character buffer to another buffer the number of times as specified by the secondary loop length.

The setLength(0) method is usually faster. However, after copying a large string it becomes slow even when copying small strings.

This is due to a peculiarity in the copy method in StringBuffer class which creates a character array of the same length as the old buffer even if the vast majority of those characters are unused.

The tests were performed on Linux using IBM's JDK 1.1.8.

The test script is a crude model of what might happen in reality. If you remain unconvinced of its results, then please send your alternative measurement scenario.