Есть много способов однозначно представить одно и то же значение с плавающей запятой в десятичном виде. Например, вы можете добавить произвольно много нулей после точного вывода (обратите внимание, что, поскольку каждая степень двух имеет десятичное представление конечной длины, то же самое происходит с каждым числом с плавающей запятой).
Критерий «когда я могу прекратить печатать лишние цифры» обычно выбирается как «вы можете прекратить печатать лишние цифры, когда вы получите точно такое же значение обратно, если вы проанализировали десятичный вывод в число с плавающей точкой» снова". Вкратце: ожидается, что на выходе с плавающей запятой "совершаются круговые поездки".
Если вы проанализируете десятичные представления 34.844479
и 34.84448
, вы обнаружите, что они оба преобразуются обратно в значение с плавающей запятой 0x420b60bf
или 01000010000010110110000010111111
. Итак, обе эти строки представляют одно и то же число с плавающей запятой. (Источник: Попробуйте сами на https://www.h-schmidt.net/FloatConverter/IEEE754.html )
Ваш вопрос сводится к «Почему разные библиотеки времени выполнения печатают различные значения для одного и того же числа с плавающей точкой? », на что ответ« библиотека, как правило, должна выяснить, когда прекратить печатать цифры, они не обязаны останавливаться на минимуме ». До тех пор, пока вы сможете вернуть тот же самый float при повторном его анализе, библиотека сделала свое дело.
Если вы хотите увидеть точно такие же десятичные строки , вы можете добиться этого с помощью соответствующих параметров форматирования.
Стандартная идиома:
long startTime = System.nanoTime();
doSomething();
long elapsedTime = System.nanoTime() - startTime;
не проверено, но что-то вроде:
long delta = System.nanoTime();
try {
// do your stuff
} finally {
delta = System.nanoTime() - delta;
}
Здесь приведен пример кода:
http://www.goldb.org/stopwatchjava.html
/*
Copyright (c) 2005, Corey Goldberg
StopWatch.java is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
*/
public class StopWatch {
private long startTime = 0;
private long stopTime = 0;
private boolean running = false;
public void start() {
this.startTime = System.currentTimeMillis();
this.running = true;
}
public void stop() {
this.stopTime = System.currentTimeMillis();
this.running = false;
}
//elaspsed time in milliseconds
public long getElapsedTime() {
long elapsed;
if (running) {
elapsed = (System.currentTimeMillis() - startTime);
}
else {
elapsed = (stopTime - startTime);
}
return elapsed;
}
//elaspsed time in seconds
public long getElapsedTimeSecs() {
long elapsed;
if (running) {
elapsed = ((System.currentTimeMillis() - startTime) / 1000);
}
else {
elapsed = ((stopTime - startTime) / 1000);
}
return elapsed;
}
//sample usage
public static void main(String[] args) {
StopWatch s = new StopWatch();
s.start();
//code you want to time goes here
s.stop();
System.out.println("elapsed time in milliseconds: " + s.getElapsedTime());
}
}
То, как я бы это сделал, это просто запустить его в цикле несколько раз. Например, если вы запустите его 1000 раз и синхронизируете его, это даст вам миллисекунды. Запустите его 1 000 000 раз, и это даст вам микросекунды.
Если вы также хотите узнать, почему это занимает столько времени, сколько нужно, вы можете просто приостановить его несколько раз (например, 10), пока он работает, и это будет скажу вам, что он делает и почему.
Проблема с методом get System.xxx заключается в том, что самому методу для вычисления требуется несколько миллисекунд. Обычно «общепринятый» способ сделать это - выполнить тест несколько десятков тысяч раз и вычислить среднее значение этого значения.
Кроме того, в зависимости от вашей ОС существует нечто, называемое временная гранулярность ( пример для windows). Это наименьшее количество времени, которое ваша ОС может вычислить. В некоторых ОС - миллисекунда, в других - наносекунда. Это может или не может иметь отношение к вашему делу.