Lazy vs Strict implementations of data structures

  • Data.XYMap.Lazy and Data.XYMap.Strict

for XY in {"", "Int", "Hash"}: The *.Strict variant forces the evaluation of the mapped-to values to WHNF before they are placed in the map.

The big advantage of that is more predictable space and time behaviour, since it is much harder to build up huge thunks, especially for types of the form (ConstructorN UnboxedValueTypeN), that is impossible.

The disadvantage – I remember there were examples brought up when it was discussed whether the strict or lazy variants should become the default, but I don’t remember anything in particular.

Ah, just remembered a use case: One can tie a knot with the Lazy variants, that is of course impossible with the Strict versions! So if you do such things: Lazy.

I use the Strict versions by default. Until I need to tie knots or encounter another use case where I consider the Lazy variants superior, I don’t know when I would use them.

  • Data.(ByteString/Text).Lazy and Data.(ByteString/Text).Strict

The strict versions use one monolithic chunk of storage for the payload, that means you have fast random access, not only sequentially, but also backwards from the end, or jumping to and fro.

The lazy versions are basically head-strict lists of strict chunks, their strength is that sequential consumption of them can often be done in constant small memory, that is great if you need to sequentially process large files.

For small(ish) data, definitely use the Strict variants, for huge data the Lazy variants if the data is processed (more or less) sequentially.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)