Эффективная вставка в коллекцию длинных значений

Question

Я делаю сбор метрик для фрагмента кода и хочу сохранить коллекцию временных различий (тип примитив long) для последующего анализа

Операция вставки для этой коллекции должна быть максимально эффективной, чтобы добавить к результатам наименьшие накладные расходы.

Я впервые проверил коллекцию ConcurrentLinkedQueue<Long>. Это дало худшую производительность (вероятно, из-за упаковки / распаковки)

В настоящее время я остановился на использовании синхронизированного gnu.trove.TLongArrayList, который почти в 7 раз быстрее для набора данных длиной 5 миллионов.

Будем с благодарностью признаны за любые рекомендации для других библиотек коллекций, которые могут быть хорошими кандидатами для сравнения в этом сценарии использования. Я взглянул на API-интерфейс guava, но ничего не смог найти

Answer 1

В разработке находится новая версия Trove (последняя - 3.0.0-RC2). На этой странице написано, что Trove 3 на 10-20% быстрее, чем Trove 2.

К сожалению:

• В Trove 3 есть изменения в совместимости API.
• Онлайн Javadocs еще не доступны.
• Вы не можете получить его от Maven Central.(Вы даже не можете получить Trove 2.1.0 ... тск, тск.)

Answer 2

Чтобы повысить производительность, вы можете сократить размер данных. Если вы можете уменьшить его до int, это поможет. (часто разница между двумя вызовами nanoTime () составляет менее 2 миллиардов)

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

Если вы знаете максимальное количество записываемых вами значений, вы можете использовать int[] с возможным counter, если максимальное значение не достигнуто. Это будет быстрее, чем использование объекта.

Answer 3

Вы должны попробовать fastutil .В зависимости от сценария возможно, что fastutil работает быстрее, чем trove4j

Answer 4

Я не уверен, что ваша ситуация позволяет это сделать, но рассматривали ли вы возможность сохранения данных в отдельной несинхронизированной структуре данных для каждого потока?Что-то вроде ThreadLocal, содержащего TLongArrayList.Это устранит накладные расходы на синхронизацию.

Answer 5

Если вы заранее знаете размер коллекции, вы можете использовать один несинхронизированный массив long[] в сочетании со счетчиком AtomicInteger для получения следующей позиции вставки.