commit bfcec24f6d10028f24bf3f4d32a2144912cc771c
author Elliott Hughes <enh@google.com> Mon Sep 21 14:08:38 2009 -0700
committer Elliott Hughes <enh@google.com> Mon Sep 21 14:08:38 2009 -0700
tree ec5524e5221e90c54cb4600b68f51cd381c97b6f
parent a6a018e3be5dffc2c98fb9df0167cfd0acd55180

Consistently use Formatter's cached NumberFormat.

%f is a lot more expensive than it should be because we're not using the cached
NumberFormat (as we are for %d). Running the microbenchmark I added to the
bug (times in ms, on a Cortex A8):

                                old       new
      new Formatter %f         1732       811
      String.format %d          635       651
      String.format %f         1752       900
      reuse Formatter %f       1521       188
      Double.toString +         149       148
      Double.toString append     33        33
      StringBuilder.append      143       139

Bug: 1476

libcore/luni/src/main/java/java/util/Formatter.java

diff --git a/libcore/luni/src/main/java/java/util/Formatter.java b/libcore/luni/src/main/java/java/util/Formatter.java
index d1dd417..3196f0e 100644
--- a/libcore/luni/src/main/java/java/util/Formatter.java
+++ b/libcore/luni/src/main/java/java/util/Formatter.java
@@ -1896,7 +1896,7 @@
             }
             // output result
             FloatUtil floatUtil = new FloatUtil(result, formatToken,
-                    (DecimalFormat) NumberFormat.getInstance(locale), arg);
+                    (DecimalFormat) getNumberFormat(), arg);
             floatUtil.transform(formatToken, result);
 
             formatToken.setPrecision(FormatToken.UNSET);