Bavashi, с одним аргументом - дважды. Можно уменьшить вдвое число вызовов, явно объявив переменную var xDays=countDaysOnScoreboard(x). На мой взгляд, это не даст заметного выигрыша: компиляторы достаточно умные. Кроме того, мы уменьшаем число вызовов за счет дополнительной нагрузки на память, и совсем неочевидно что лучше.
C GC проверять стоит в первую очередь не запускается ли он слишком часто, делает ли full stop и скачет ли объем потребляемой памяти. Это - общие рекомендации при анализе производительности. В конкретном случае достаточно убедиться, что GC не срабатывает больше десятка раз за весь тест.
Про то, как это смотреть, написаны обширные статьи, в ответ их не уместить. Коротко - запустить JVM с -verbose:gc и -XX:+PrintGCApplicationStoppedTime
Добро пожаловать в мир профилирования производительности!
Построить профиль быстродействия кода - скорее исследовательская задача. Основная цель - найти самые медленные и самые "горячие" места, чтобы потом улучшать именно их.
Разница в том, что одна медленная операция может занимать 500 мсек, после оптимизации 200 мсек, но выполняется она дважды, и выигрыш будет 600 мсек. А самая горячая исполняется 100_000 раз, и оптимизация на 0.01 мсек даст прирост в 1 секунду. Но горячая операция это не та, что выполняется чаще всего, а та, которая выполняется много и одновременно относительно медленно.
Оптимизация в ненужном месте может будет стоить дорого: читаемость кода уменьшится, время потратится, а эффект незначительный.
К чему такое длинное предисловие? Вам многое придется сделать лично, т.к. производительность зависит от железа, версии ОС и JVM и много чего еще. Тема профилирования слишком обширна, и начать стоит с освоения встроенных в конкретную IDE инструментов. Я же укажу на потенциально проблемные точки:
Вызов countDaysOnScoreboard(x) дважды за цикл. Скорей всего, умная JVM все сделала сама, а метод выполняется быстро. Но вдруг? Предлагаю рассматривать эту проверку как тренировочную: вряд ли выигрыш будет большим, но анализ позволит научиться пользоваться инструментами.
Операции со строками. В тесте каждую итерацию парсятся 4 числа и строка разбивается на части. Если это занимает существенное время, то либо приходить к (де)сериализации, либо принимать время работы теста как данность.
Вывод в консоль. В тесте сто тыщ раз выводится малоинформативная строчка "test passed". Просто вывод этого на экран будет занимать время. Сравните время работы всего теста без нее с первоначальным вариантом.
Файловые операции. Вы читаете попеременно с двух файлов по одной строчке. Это вообще плохая практика, а в некоторых случаях (фрагментированный HDD, сетевое хранилище) она может привести к удручающим последствиям. Попробуйте сначала прочитать оба файла, потом запускать цикл. Современный компьютер вполне может держать в памяти 200_000 строк в памяти.
Нагрузка со стороны GC. Бывает так, что проблема не в коде, а инфраструктуре, в частности в Garbare Collector-e. Конкретно в этом случае маловероятно, но в любой непонятной ситуации стоит проверить.
Более глобальный вопрос, но из того же разряда: Что работает дольше: тестируемый код или обвязка в тесте? Возможно, ответить на него стоит как можно раньше, чтобы понимать какую часть кода профилировать дальше.
Теперь тебе будет мешать `FactoryDAO.getInstance()`, т.к. нужно замокать статический метод. PowerMock вроде это умел, но как и spy - не рекомендуется к ежедневному использованию. Используй @Autowired, разберись как работает эта магия в рабочем и тестовом коде - и будет тебе счастье.
использовать конструкции вида query="insert ...."+name +")" в настоящее время категорически нельзя! Почему - почитайте про SQL иньекции.
Безопасный подход - использовать prepared statement
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.