Lazy vs Строгие реализации структур данных

Имеется список структур данных, имеющих ленивые и строгие реализации:

Data.Map.Lazy и Data.Map.Strict
Data.IntMap.Lazy и Data.IntMap.Strict
Data.HashMap.Lazy и Data.HashMap.Strict
Data.ByteString.Lazy и Data.ByteString.Strict
Data.Text.Lazy и Data.Text

Каковы сильные и слабые стороны этих реализаций и каковы правила, которые следует соблюдать при выборе конкретного?

Ответ 1

Data.XYMap.Lazy и Data.XYMap.Strict

для XY в {"", "Int", "Hash"}: Вариант *.Strict заставляет оценивать отображаемые значения до WHNF до их размещения на карте.

Большим преимуществом этого является более предсказуемое поведение пространства и времени, так как гораздо сложнее создать огромные трюки, особенно для типов формы (ConstructorN UnboxedValueTypeN), что невозможно.

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

А, просто вспомнил случай использования: можно связать узел с вариантами Lazy, что, конечно, невозможно с версиями Strict! Итак, если вы делаете такие вещи: Lazy.

Я использую версии Strict по умолчанию. Пока мне не нужно завязывать узлы или встречаться с другим вариантом использования, когда я рассматриваю варианты Lazy выше, я не знаю, когда я их буду использовать.

Data.(ByteString/Text).Lazy и Data.(ByteString/Text).Strict

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

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

Для небольших (ish) данных обязательно используйте варианты Strict, для огромных данных варианты Lazy, если данные обрабатываются (более или менее) последовательно.

Ответ 2

Каковы сильные и слабые стороны этих реализаций и каковы правила, которые следует соблюдать при выборе конкретного?

Строгость или лень типа приводят к различной сложности конкретных операций или способов использования.

Нет жестких или быстрых правил - вместо этого вам может показаться, что они представляют собой совершенно разные типы данных.

Если вы настаиваете на некоторых рекомендациях:

ленивые структуры для данных, больших, чем память
ленивые структуры для редко используемых данных или когда вы используете небольшую часть большой структуры

И затем:

строгие структуры, если вы делаете много обновлений
строгие структуры для небольших атомных данных