34 *
35 * Usage and arguments:
36 * - Run with no argument skips the whole benchmark and exits.
37 * - Run with "-help" as first argument calls the usage() method and exits.
38 * - Run with "-doit" runs the benchmark with summary details.
39 * - Run with "-verbose" provides additional details on the run.
40 *
41 * Example run :
42 * java -Xms500m -Xmx500m -XX:NewSize=400m FormatMicroBenchmark -doit -verbose
43 *
44 * Running with jtreg:
45 * The jtreg header "run" tag options+args must be changed to avoid skipping
46 * the execution. here is an example of run options:
47 * "main/othervm -Xms500m -Xmx500m -XX:NewSize=400m FormatMicroBenchmark -doit"
48 *
49 * Note:
50 * - Vm options -Xms, -Xmx, -XX:NewSize must be set correctly for
51 * getting reliable numbers. Otherwise GC activity may corrupt results.
52 * As of jdk80b48 using "-Xms500m -Xmx500m -XX:NewSize=400m" covers
53 * all cases.
54 * - Optionally using "-XX:+printGC" option provides information that
55 * helps checking any GC activity while benches are run.
56 *
57 * Vm Options:
58 * - Vm options to use (as of jdk80b48):
59 * fast-path case : -Xms128m -Xmx128m -XX:NewSize=100m
60 * non fast-path case: -Xms500m -Xmx500m -XX:NewSize=400m
61 * or use worst case (non fast-path above) with both types of algorithm.
62 *
63 * - use -XX:+PrintGC to verify memory consumption of the benchmarks.
64 * (See "Checking Memory Consumption" below).
65 *
66 * Description:
67 *
68 * Fast-path algorithm for format(double...) call stack is very different of
69 * the standard call stack. Where the standard algorithm for formating double
70 * uses internal class sun.misc.FloatingDecimal and its dtoa(double) method to
71 * provide digits, fast-path embeds its own algorithm for binary to decimal
72 * string conversion.
73 *
74 * FloatingDecimal always converts completely the passed double to a string.
75 * Fast-path converts only to the needed digits since it follows constraints
76 * on both the pattern rule, the DecimalFormat instance properties, and the
77 * passed double.
78 *
79 * Micro benchmarks below measure the throughput for formating double values
80 * using NumberFormat.format(double) call stack. The standard DecimalFormat
81 * call stack as well as the fast-path algorithm implementation are sensitive
82 * to the nature of the passed double values regarding throughput performance.
83 *
149 * first three runs are taken into account in the time measurement (server jit
150 * compiler shows to have done full optimization in most cases after the
151 * second run, given a base number of iterations set to 500000).
152 *
153 * The program cleans up memory (stabilizeMemory() method) between each run of
154 * the benchmarks to make sure that no garbage collection activity happens in
155 * measurements. However that does not preclude incremental GCs activity that
156 * may happen during the micro-benchmark if -Xms, -Xmx, and NewSize options
157 * have not been tuned and set correctly.
158 *
159 * Checking Memory Consumption:
160 *
161 * For getting confidence in the throughput numbers, there must not give any
162 * GC activity during the benchmark runs. That means that specific VM options
163 * related to memory must be tuned for any given implementation of the JDK.
164 *
165 * Running with "-verbose" arguments will provide clues of the memory consumed
166 * but is not enough, since any unexpected incremental GC may lower
167 * artificially the estimation of the memory consumption.
168 *
169 * Options to set are -Xms, -Xmx, -XX:NewSize, plus -XX:+PrintGC to evaluate
170 * correctly the values of these options. When running "-verbose", varying
171 * numbers reported for memory consumption may indicate bad choices for these
172 * options.
173 *
174 * For jdk80b25, fast-path shows a consuption of ~60Mbs for 500000 iterations
175 * while a jdk without fast-path will consume ~260Mbs for each benchmark run.
176 * Indeed these values will vary depending on the jdk used.
177 *
178 * Correct option settings found jdk80b48 were :
179 * fast-path : -Xms128m -Xmx128m -XX:NewSize=100m
180 * non fast-path : -Xms500m -Xmx500m -XX:NewSize=400m
181 * Greater values can be provided safely but not smaller ones.
182 * ----------------------------------------------------------------------
183 */
184
185 import java.util.*;
186 import java.text.NumberFormat;
187 import java.text.DecimalFormat;
188
189 public class FormatMicroBenchmark {
200 // Should we really execute the benches ? (no by default).
201 private static boolean DoIt = false;
202
203 // Prints out a message describing how to run the program.
204 private static void usage() {
205 System.out.println(
206 "This is a set of micro-benchmarks testing throughput of " +
207 "java.text.DecimalFormat.format(). It never fails.\n\n" +
208 "Usage and arguments:\n" +
209 " - Run with no argument skips the whole benchmark and exits.\n" +
210 " - Run with \"-help\" as first argument prints this message and exits.\n" +
211 " - Run with \"-doit\" runs the benchmark with summary details.\n" +
212 " - Run with \"-verbose\" provides additional details on the run.\n\n" +
213 "Example run :\n" +
214 " java -Xms500m -Xmx500m -XX:NewSize=400m FormatMicroBenchmark -doit -verbose\n\n" +
215 "Note: \n" +
216 " - Vm options -Xms, -Xmx, -XX:NewSize must be set correctly for \n" +
217 " getting reliable numbers. Otherwise GC activity may corrupt results.\n" +
218 " As of jdk80b48 using \"-Xms500m -Xmx500m -XX:NewSize=400m\" covers \n" +
219 " all cases.\n" +
220 " - Optionally using \"-XX:+printGC\" option provides information that \n" +
221 " helps checking any GC activity while benches are run.\n\n" +
222 "Look at the heading comments and description in source code for " +
223 "detailed information.\n");
224 }
225
226 /* We will call stabilizeMemory before each call of benchFormat***().
227 * This in turn tries to clean up as much memory as possible.
228 * As a safe bound we limit number of System.gc() calls to 10,
229 * but most of the time two calls to System.gc() will be enough.
230 * If memory reporting is asked for, the method returns the difference
231 * of free memory between entering an leaving the method.
232 */
233 private static long stabilizeMemory(boolean reportConsumedMemory) {
234 final long oneMegabyte = 1024L * 1024L;
235
236 long refMemory = 0;
237 long initialMemoryLeft = Runtime.getRuntime().freeMemory();
238 long currMemoryLeft = initialMemoryLeft;
239 int nbGCCalls = 0;
240
|
34 *
35 * Usage and arguments:
36 * - Run with no argument skips the whole benchmark and exits.
37 * - Run with "-help" as first argument calls the usage() method and exits.
38 * - Run with "-doit" runs the benchmark with summary details.
39 * - Run with "-verbose" provides additional details on the run.
40 *
41 * Example run :
42 * java -Xms500m -Xmx500m -XX:NewSize=400m FormatMicroBenchmark -doit -verbose
43 *
44 * Running with jtreg:
45 * The jtreg header "run" tag options+args must be changed to avoid skipping
46 * the execution. here is an example of run options:
47 * "main/othervm -Xms500m -Xmx500m -XX:NewSize=400m FormatMicroBenchmark -doit"
48 *
49 * Note:
50 * - Vm options -Xms, -Xmx, -XX:NewSize must be set correctly for
51 * getting reliable numbers. Otherwise GC activity may corrupt results.
52 * As of jdk80b48 using "-Xms500m -Xmx500m -XX:NewSize=400m" covers
53 * all cases.
54 * - Optionally using "-Xlog:gc" option provides information that
55 * helps checking any GC activity while benches are run.
56 *
57 * Vm Options:
58 * - Vm options to use (as of jdk80b48):
59 * fast-path case : -Xms128m -Xmx128m -XX:NewSize=100m
60 * non fast-path case: -Xms500m -Xmx500m -XX:NewSize=400m
61 * or use worst case (non fast-path above) with both types of algorithm.
62 *
63 * - use -Xlog:gc to verify memory consumption of the benchmarks.
64 * (See "Checking Memory Consumption" below).
65 *
66 * Description:
67 *
68 * Fast-path algorithm for format(double...) call stack is very different of
69 * the standard call stack. Where the standard algorithm for formating double
70 * uses internal class sun.misc.FloatingDecimal and its dtoa(double) method to
71 * provide digits, fast-path embeds its own algorithm for binary to decimal
72 * string conversion.
73 *
74 * FloatingDecimal always converts completely the passed double to a string.
75 * Fast-path converts only to the needed digits since it follows constraints
76 * on both the pattern rule, the DecimalFormat instance properties, and the
77 * passed double.
78 *
79 * Micro benchmarks below measure the throughput for formating double values
80 * using NumberFormat.format(double) call stack. The standard DecimalFormat
81 * call stack as well as the fast-path algorithm implementation are sensitive
82 * to the nature of the passed double values regarding throughput performance.
83 *
149 * first three runs are taken into account in the time measurement (server jit
150 * compiler shows to have done full optimization in most cases after the
151 * second run, given a base number of iterations set to 500000).
152 *
153 * The program cleans up memory (stabilizeMemory() method) between each run of
154 * the benchmarks to make sure that no garbage collection activity happens in
155 * measurements. However that does not preclude incremental GCs activity that
156 * may happen during the micro-benchmark if -Xms, -Xmx, and NewSize options
157 * have not been tuned and set correctly.
158 *
159 * Checking Memory Consumption:
160 *
161 * For getting confidence in the throughput numbers, there must not give any
162 * GC activity during the benchmark runs. That means that specific VM options
163 * related to memory must be tuned for any given implementation of the JDK.
164 *
165 * Running with "-verbose" arguments will provide clues of the memory consumed
166 * but is not enough, since any unexpected incremental GC may lower
167 * artificially the estimation of the memory consumption.
168 *
169 * Options to set are -Xms, -Xmx, -XX:NewSize, plus -Xlog:gc to evaluate
170 * correctly the values of these options. When running "-verbose", varying
171 * numbers reported for memory consumption may indicate bad choices for these
172 * options.
173 *
174 * For jdk80b25, fast-path shows a consuption of ~60Mbs for 500000 iterations
175 * while a jdk without fast-path will consume ~260Mbs for each benchmark run.
176 * Indeed these values will vary depending on the jdk used.
177 *
178 * Correct option settings found jdk80b48 were :
179 * fast-path : -Xms128m -Xmx128m -XX:NewSize=100m
180 * non fast-path : -Xms500m -Xmx500m -XX:NewSize=400m
181 * Greater values can be provided safely but not smaller ones.
182 * ----------------------------------------------------------------------
183 */
184
185 import java.util.*;
186 import java.text.NumberFormat;
187 import java.text.DecimalFormat;
188
189 public class FormatMicroBenchmark {
200 // Should we really execute the benches ? (no by default).
201 private static boolean DoIt = false;
202
203 // Prints out a message describing how to run the program.
204 private static void usage() {
205 System.out.println(
206 "This is a set of micro-benchmarks testing throughput of " +
207 "java.text.DecimalFormat.format(). It never fails.\n\n" +
208 "Usage and arguments:\n" +
209 " - Run with no argument skips the whole benchmark and exits.\n" +
210 " - Run with \"-help\" as first argument prints this message and exits.\n" +
211 " - Run with \"-doit\" runs the benchmark with summary details.\n" +
212 " - Run with \"-verbose\" provides additional details on the run.\n\n" +
213 "Example run :\n" +
214 " java -Xms500m -Xmx500m -XX:NewSize=400m FormatMicroBenchmark -doit -verbose\n\n" +
215 "Note: \n" +
216 " - Vm options -Xms, -Xmx, -XX:NewSize must be set correctly for \n" +
217 " getting reliable numbers. Otherwise GC activity may corrupt results.\n" +
218 " As of jdk80b48 using \"-Xms500m -Xmx500m -XX:NewSize=400m\" covers \n" +
219 " all cases.\n" +
220 " - Optionally using \"-Xlog:gc\" option provides information that \n" +
221 " helps checking any GC activity while benches are run.\n\n" +
222 "Look at the heading comments and description in source code for " +
223 "detailed information.\n");
224 }
225
226 /* We will call stabilizeMemory before each call of benchFormat***().
227 * This in turn tries to clean up as much memory as possible.
228 * As a safe bound we limit number of System.gc() calls to 10,
229 * but most of the time two calls to System.gc() will be enough.
230 * If memory reporting is asked for, the method returns the difference
231 * of free memory between entering an leaving the method.
232 */
233 private static long stabilizeMemory(boolean reportConsumedMemory) {
234 final long oneMegabyte = 1024L * 1024L;
235
236 long refMemory = 0;
237 long initialMemoryLeft = Runtime.getRuntime().freeMemory();
238 long currMemoryLeft = initialMemoryLeft;
239 int nbGCCalls = 0;
240
|