Hello,
I¹m working on Bug 49164 (
https://issues.apache.org/bugzilla/show_bug.cgi?id=49165)
Have a question:
Any hidden reasons, why following construction was used for creating %t
pattern?:
private SimpleDateFormat dayFormatter = new SimpleDateFormat("dd");
private SimpleDateFormat monthFormatter = new SimpleDateFormat("MM");
private SimpleDateFormat yearFormatter = new SimpleDateFormat("yyyy");
private SimpleDateFormat timeFormatter = new SimpleDateFormat("HH:mm:ss");
...
StringBuilder current = new StringBuilder(32);
current.append('[');
current.append(struct.dayFormatter.format(date));
current.append('/');
current.append(lookup(struct.monthFormatter.format(date)));
current.append('/');
current.append(struct.yearFormatter.format(date));
current.append(':');
current.append(struct.timeFormatter.format(date));
current.append(' ');
current.append(getTimeZone(date));
current.append(']');
struct.currentDateString = current.toString();
Instead of this one:
private SimpleDateFormat timeFormatter = new
SimpleDateFormat("[dd/MMM/yyyy:HH:mm:ss]");
...
struct.currentDateString = struct.timeFormatter.format(date);
I¹ve added one more test with this structure to
org.apache.catalina.valves.Benchmarks and looks like the last solution the
shortest and fastest option. Plus we can pass any pattern from configuration
(#49165 enhancement intention):
TimeDateElementBenchmarkTest_Sync: 5 threads and 10000000 iterations using
Syncs took 3392ms
TimeDateElementBenchmarkTest_Local: 5 threads and 10000000 iterations using
ThreadLocals took 2551ms
TimeDateElementBenchmarkTest_LocalStruct: 5 threads and 10000000 iterations
using single ThreadLocal took 2237ms
TimeDateElementBenchmarkTest_LocalStruct_SBuilder: 5 threads and 10000000
iterations using single ThreadLocal, with StringBuilder took 2196ms
TimeDateElementBenchmarkTest_LocalStruct_SimpleDateFormat: 5 threads and
10000000 iterations using single ThreadLocal SimpleDateFormat took 2152ms
P. S. My thanks to Mark Thomas for buglist to start.
