Большая разница во временных метках при многократном запуске одного и того же приложения на эмуляторе

Question

В приложении для Android я пытаюсь выполнить операцию экспоненциального модуля и хочу рассчитать время, затраченное на этот процесс. Итак, я создал 2 отметки времени, одну перед операцией, а другую сразу после операции

Calendar calendar0 = Calendar.getInstance();
java.util.Date now0 = calendar0.getTime();
java.sql.Timestamp currentTimestamp0 = new java.sql.Timestamp(now0.getTime());

BigInteger en = big.modPow(e, n);

Calendar calendar1 = Calendar.getInstance();
java.util.Date now1 = calendar1.getTime();
java.sql.Timestamp currentTimestamp1 = new java.sql.Timestamp(now1.getTime());

Разница во времени, сообщаемая этими двумя временными метками, изменяется в большом диапазоне для одних и тех же входов, когда я запускаю приложение несколько раз. Это дает время в диапазоне [200 нс-6 нс]

Может кто-то указать причину такого результата / что-то, что я делаю неправильно?

Answer 1

Ну, во-первых, вы очень запутанно выбираете время.Вот кое-что, что дает такую ​​же точность, но более простую:

long start = System.currentTimeMillis();
BigInteger en = big.modPow(e, n);
long end = System.currentTimeMillis();

Обратите внимание, что java.util.Date имеет точность только с точностью до миллисекунды, и использование того же значения и помещение его в java.sql.Timestamp не делаетволшебным образом сделать это более точным.Таким образом, любой результат за миллисекунду (6 нс-200 нс) явно ложный - в основном все, что меньше миллисекунды, равно 0.

Вы можете быть в состоянии получить более точныйчтение с использованием System.nanoTime - я не знаю, поддерживается ли это на Android.Также могут быть доступны альтернативные высокоточные таймеры.

Теперь о том, почему операции могут фактически занимать очень различное количество записанного времени:

• Степень детализации системных часов, использованных выше.вполне может быть значительно меньше, чем 1 мс.Например, если он измеряет не меньше 15 мс, вы можете увидеть, что некоторые операции предположительно занимают 0 мс, а некоторые - 15 мс, хотя они на самом деле занимают одинаковое количество времени.
• Там легкодругие факторы, наиболее очевидным из которых является сборка мусора

Answer 2

Большая часть причины изменения заключается в том, что ваше приложение запускается виртуальной машиной, работающей в операционной системе общего назначения, на эмулируемом компьютере, который работает в операционной системе общего назначения на реальном компьютере.

За исключением вашего приложения, каждая из вещей в этой куче (JVM, на которой работает ваше приложение, ОС Linux на Android, эмулятор и любая другая ОС, на которой он работает), может использовать процессор (реальный или виртуальный) для выполнения чего-то другого в любое время на любой срок. Эти циклы уберут от выполнения вашей программы и добавят к ее времени выполнения настенных часов. Результатом является полностью недетерминированное поведение.

Если вы посчитаете использованные циклы процессора эмулятора и не учитываете то, что делает Java за кулисами, я не сомневаюсь, что стандартное отклонение во времени выполнения будет намного ниже, чем то, что вы видите для тех же входных данных. Эмулируемая среда Android не место для тестирования алгоритмов, потому что слишком много переменных, которыми вы не можете управлять.

Answer 3

Выполните больше вычислений в пробной версии, чтобы ожидаемое время составило несколько миллисекунд.

Подумайте о том, чтобы сделать вывод для logcat, записать его на ПК и затем обработать logcat, чтобы выбрать только испытания без промежуточных сообщений платформы о сборе мусора или рутинных фоновых операциях.

Answer 4

Вы не можете делать какие-либо выводы, только запустив одну функцию. Там так много всего происходит. У вас нет контроля над основной операционной системой Linux, выполняющей циклы, не говоря уже о виртуальной машине Java, и все же все остальные программы работают. Попробуйте запустить его 1000 или 10000 раз