In article <hgpnhs$v8s$1@news.albasani.net>, Lew <noone@lewscanon.com>
wrote:
Kevin McMurtrie wrote:
private static final NumberFormat s_fmt=
new DecimalFormat("0.################");
...
final String str;
synchronized (s_fmt)
{
str= s_fmt.format(d);
}
...
In a heavily multi-threaded, high-throughput environment that synchronized
static formatter could be quite a choke point. If that turns out to be the
case, one could use
str = new DecimalFormat("0.################").format(d);
Naturally you'd want to elevate the string to a final constant either way.
This assumes you don't mind keeping the decimal point when the fractional
part
is zero.
Java has come a long way in optimization of uncontended locks, but contended
ones are inherently a bitch. It can be astonishing how much time is spent
waiting to acquire a lock in a contentious scenario, to the severe detriment
of throughput. On projects where I've seen such things actually measured, a
highly-contended synchronization lock has been the major throughput killer,
beating even database I/O despite the latter being very poorly handled in
some
cases. And that was with Java 5.
If the formatter is lightly touched, then the lock won't be such an issue.
The DecimalFormat constructor is massive and it has synchronization on
globals. It's definitely not appropriate for temporary use in high
performance code.
This kind of problem is exactly what ThreadLocal can solve:
private static final ThreadLocal<NumberFormat> s_fmt=
new ThreadLocal<NumberFormat>()
{
@Override protected NumberFormat initialValue()
{
return new DecimalFormat("0.################");
}
};
...
final String str= s_fmt.get().format(d);
...
Of course, if throughput was top priority for this example I'd write a
number formatter from scratch rather than pay the overhead of
DecimalFormat's dynamic formatting. That could easily be a 500x speedup
in total long-term throughput.
enlightened by your information. The lesson is that when one needs to eke out
and under what conditions. If the constructor were light weight, my advice
would work. That the constructor is heavy indicates your advice applies. If
In all cases, optimization without measurement risks being foolish. It was