Clean way to write Double into String without the trailing ".0" ?

K

Kevin McMurtrie

[QUOTE="Lew said:
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.[/QUOTE]

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.
 
A

Arved Sandstrom

Kevin said:
[QUOTE="Lew said:
private static final NumberFormat s_fmt=
new DecimalFormat("0.################");

...
final String str;
synchronized (s_fmt)
{
str= s_fmt.format(d);
}
...
I thought so, too, but that pattern doesn't eliminate the decimal point when
the fractional part is zero.

When I run it, 10.0d returns "10" and 10.1d returns "10.1".[/QUOTE]

This is the one part of the original problem statement that may have to
be rethought. Does the OP really want that decimal point to be dropped
if the fractional part is zero? There is, after all, a big difference
between the numbers "10" and "10."

AHS
 
A

Andreas Leitgeb

abc said:
If what you mean by this is the (String)"\\.0$" I had to put it in
because I found I get an error message there if I remove the (String)
part like this:
s = s.replaceAll("\\.0$", ""); // error, with (String) removed

That's just impossible.

Except, of course, if it is really a non-compliant Java-compiler
that you fed your source to.
 
T

Tom McGlynn

TomMcGlynnwrote:

OK, thanks.

There has been a couple of mentions of the "redundant cast".

If what you mean by this is the (String)"\\.0$" I had to put it in
because I found I get an error message there if I remove the (String)
part like this:

s = s.replaceAll("\\.0$", "");  // error, with (String) removed

The literal "\\.0$" is already a String, so casting it to String
should
have no effect. If you can show the exact code you use (i.e., at
least the entire method and preferably a working program) and the
error message you get, I suspect that something else will shake out.
E.g., for me the following program compiles and runs without problem.

public class Test {
public static void main(String[] args) throws Exception {
double x = Double.parseDouble(args[0]);
String s = Double.toString(x);
s = s.replaceAll("\\.0$", "");
System.out.println("S is now:"+s);
}
}

Regards,
Tom McGlynn
 
L

Lew

Kevin said:
[QUOTE="Lew said:
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.[/QUOTE]

While I'm suspicious of claims like "500x speedup" without evidence, I am
enlightened by your information. The lesson is that when one needs to eke out
maximum performance (memory or speed), one needs to know what they're using
and under what conditions. If the constructor were light weight, my advice
would work. That the constructor is heavy indicates your advice applies. If
the throughput requirements on the object were light, the original simple
synchronization would suffice.

In all cases, optimization without measurement risks being foolish. It was
measurement that revealed the penalty of lock contention in the scenario to
which I alluded, on a structure that had been introduced in a benighted
attempt to optimize throughput.
 
A

abc

Tom said:
The literal "\\.0$" is already a String, so casting it to String
should
have no effect. If you can show the exact code you use (i.e., at
least the entire method and preferably a working program) and the
error message you get, I suspect that something else will shake out.
E.g., for me the following program compiles and runs without problem.

public class Test {
public static void main(String[] args) throws Exception {
double x = Double.parseDouble(args[0]);
String s = Double.toString(x);
s = s.replaceAll("\\.0$", "");
System.out.println("S is now:"+s);
}
}

Regards,
Tom McGlynn

You're right. Apparently I was a little confused about the error message
I saw. I was thrashing about and experimenting with that part of the
code and there must have been some other issue that caused the error.

Trying it again now, it turns out it works perfectly well without the cast.
 
M

markspace

Lew said:
While I'm suspicious of claims like "500x speedup" without evidence, I
am enlightened by your information.


I agree with the measurement part. Particularly, with Java 7 coming
soon, if Kevin has any direct experience with DecimalFormat being slow,
it might be a good idea to submit an RFE to Sun about it. 500x speed
improvement on something like simple formatting seems to be begging for
refactoring.
 
K

Kevin McMurtrie

markspace said:
I agree with the measurement part. Particularly, with Java 7 coming
soon, if Kevin has any direct experience with DecimalFormat being slow,
it might be a good idea to submit an RFE to Sun about it. 500x speed
improvement on something like simple formatting seems to be begging for
refactoring.

That would be a ~500x speed-up by hard-coding and optimizing the
specific format needed. DecimalFormat performs nicely as general
purpose class that does just about everything.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top