Микротест, сравнивающий изменяемые и неизменяемые коллекции Scala с коллекциями java.util.concurrent.*

Существуют ли какие-либо опубликованные микротесты, которые сравнивают изменяемые и неизменяемые коллекции Scala друг с другом и коллекциями в java.util.concurrent в многопоточных средах? Меня особенно интересуют случаи, когда читателей намного больше, чем авторов, например кэширование HashMaps в коде на стороне сервера.

Микротесты коллекций Clojure также будут приемлемы, поскольку их алгоритмы аналогичны тем, которые используются в постоянных коллекциях Scala 2.8.

Я напишу свои собственные, если они еще не сделаны, но написать хорошие микро-тесты не так уж и просто.


person Ralph    schedule 27.09.2011    source источник
comment
Я думаю, что крайне маловероятно, что вы получите какой-либо разумный тест, который сравнивает изменяемые и неизменяемые коллекции, потому что дизайн самого приложения отличается.   -  person Daniel C. Sobral    schedule 27.09.2011
comment
@Daniel: В настоящее время у нас есть некоторый код сервера Java, который содержит HashMaps, которые считываются около 1 000 000 раз при каждой записи. В коде используется synchronized, но читатели платят штраф за все эти оспариваемые чтения, даже если данные фактически неизменяемы. Я думал, что смогу использовать постоянные коллекции из functionsjava и блокировать только при замене старой коллекции новой скопированной коллекцией, содержащей новый элемент.   -  person Ralph    schedule 27.09.2011
comment
Похоже на разумное ожидание, и это иллюстрирует проблему с тестами. Если вы тестируете такую ​​нагрузку, вы делаете выбор в пользу неизменности. Но обратите внимание, что при использовании неизменяемых карт вы должны заменять карту при каждом обновлении, а это означает, что вам нужно каким-то образом сериализовать все обновления. Сама карта может быть указана volatile, если вы не возражаете против того, чтобы чтение отставало от записи.   -  person Daniel C. Sobral    schedule 28.09.2011


Ответы (3)


Вот некоторые результаты сравнения хеш-карт Java, хэш-карт Scala, параллельных хэш-карт Java, списков параллельных пропусков Java, параллельных массивов Java и параллельных коллекций Scala здесь (в конце технического отчета):

http://infoscience.epfl.ch/record/165523/files/techrep.pdf

Более подробное сравнение concurrent skip lists и Java concurrent hash maps есть здесь (также в конце основной части отчета, перед приложением):

http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf

Эти микротесты ориентированы на тестирование производительности одной операции. Если вы планируете писать свои собственные тесты, это, вероятно, будет полезно:

http://buytaert.net/files/oopsla07-georges.pdf

person axel22    schedule 28.09.2011
comment
Вы можете найти исходный код некоторых тестов из первой статьи здесь: lampsvn.epfl.ch/svn-repos/scala/scala/trunk/test/benchmarks, но они несколько неструктурированы. Для второго: github.com/axel22/Ctries загляните в src/bench. - person axel22; 28.09.2011
comment
Вот подробные тесты операций сбора данных в Scala: github.com/scalameter/scalameter/tree/master/src/test/scala/org/ - person axel22; 30.12.2014

Сравнительный анализ коллекций Scala Ли Хаойи представляет собой подробное и всестороннее исследование, посвященное вашему запросу. Цитировать здесь слишком долго.

person Mike Slinn    schedule 14.10.2016

Почему бы вам тогда не попробовать использовать java.util.concurrent.ConcurrentHashMap? таким образом вам не нужно синхронизироваться, и ваш миллион чтений будет намного быстрее (так же, как и запись).

person Chochos    schedule 27.09.2011
comment
Я считаю, что это заблуждение. Если вы читаете (изменяемое) значение из HashMap, обновляете это значение, а затем пытаетесь вернуть его обратно, вы все равно должны синхронизировать операцию. Я не уверен, что вы можете сделать это с replace. - person Ralph; 28.09.2011
comment
Другим вариантом было бы использование STM Clojure (вы можете использовать его из Java). Хотя я не уверен, как вы будете использовать его с HashMap... - person Chochos; 28.09.2011