Производительность HashMap <String, Comparable> по сравнению с HashMap <String, Object> - Java

Question

All

Я работаю над существующей системой, в которой разработчик определил множество HashMaps со следующим определением:

HashMap<String, Comparable> x = new HashMap<String, Comparable>();

Теперь абсолютно нет необходимости сравнивать часть value хеш-карты, поскольку она просто представляет только один фрагмент информации. Разработчик использовал Comparable, поскольку единственными ожидаемыми значениями были типы String и int (преобразованные в объект Integer), и разработчик предположил, что лучший способ хранения обоих типов данных - это использование сопоставимого интерфейса.

Итак, я пошел дальше и изменил код, поскольку здесь не было смысла сравнивать, определив HashMap как:

HashMap<String, Object> y = new HashMap<String, Object>();

Я рассчитал время выполнения кода до и после изменения. Я немного удивлен тем, почему после развертывания моих изменений выполнение кода занимает больше времени (хотя в настоящее время это не является узким местом в производительности).

Может кто-нибудь помочь мне понять изменение в поведении из-за обновлений моего кода?

Answer 1

Оба показателя идентичны с точки зрения производительности, так как значение не используется для хеширования (только ключ).

Как вы синхронизируете свой код?Убедитесь, что вы тестируете каждый тестовый случай отдельно. Не делайте следующее, так как второй тест будет иметь преимущество, поскольку первый тест будет иметь «прогретую» JVM.Я предполагаю, что ваш тест некорректен или вы видите нормальные изменения времени выполнения.

public static void main(String[] args) {
    for loop {
        test HashMap<String, Comparable>
    }

    for loop {
        test HashMap<String, Object>
    }
}

Answer 2

Нет никакой разницы. Информация о типе стирается во время выполнения, поэтому, возможно, проблема в другом месте.

Answer 3

Я предполагаю, что если вы не делаете что-то в другом месте, что означает снижение производительности (я не вижу причин, почему вы должны увидеть падение только из того, что вы упомянули), это то, что используемый вами тест является ошибочным.Использование currentTimeMillis() или даже nanoTime() не будет учитывать прогрев JIT, оптимизацию различных операций быстрее, чем другие, или что-то подобное - и любое изменение в вашем коде может повлиять на это таким образом.

Мой совет - использовать профилировщик, чтобы получить более реальное представление о том, сколько времени это займет - если при использовании этого подхода оно значительно дольше, вы можете начать изучать проблемы с кодом.Я просто боюсь, что если вы полагаетесь на тривиальные currentTimeMillis() звонки, вы, возможно, в конечном итоге попытаетесь отследить проблемы с производительностью, которые на самом деле не существуют (по крайней мере, там, где вы думаете, что они есть).