You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that this library does currently not provide fully strict lists. They can be added if they are really required. However, in many cases one probably wants to use unboxed or strict boxed vectors from the vector library (http://hackage.haskell.org/package/vector) instead of strict lists. Moreover, instead of Strings one probably wants to use strict Text values from the text library (http://hackage.haskell.org/package/text).
I agree with that advice. I think I have a use case for a strict list, though. Maybe you can provide feedback in how far it is valid and this issue can serve to elaborate the usefulness of a strict List type.
I use a foldable (a vanilla lazy list) to fold it into another foldable (I use a strict list here). I want that second foldable to be strict in its argument type to avoid the memory load that otherwise comes with the thunks.
Those are the steps of my algorithm:
My first list contains between 2'000'000 and 4'000'000 words and has the type [Text].
I then run parseSeries on every word, a CPU-heavy algorithm of type Text -> Either ParseError [RawSteno]. Because it's CPU-heavy, I run it concurrently. The result is collected in the strict list, which has less entries than the list of words from Step 1.
Finally, the pairs (Text, [RawSteno]) are folded for into a strict hashmap. It's not just HashMap.fromList, because of some further logic where entries are checked for collisions with former entries. That same logic requires this step to be single-threaded again, which is fine given that it's not nearly as performance-heavy as Step 2.
I don't see a reason to work with vector, when I really just need a foldable that is strict in the argument type. I do understand that I could work with vector. Maybe someone can point out that I should.
Btw, if all were single threaded, I would benefit from Haskell's laziness. Haskell could rush to step 3 for every word of Step 1. With concurrency I get a good speed-up but also the requirement to collect that strict foldable in Step 2 entirely before I can move on.
The text was updated successfully, but these errors were encountered:
Quoting the package documentation
I agree with that advice. I think I have a use case for a strict list, though. Maybe you can provide feedback in how far it is valid and this issue can serve to elaborate the usefulness of a strict List type.
I use a foldable (a vanilla lazy list) to fold it into another foldable (I use a strict list here). I want that second foldable to be strict in its argument type to avoid the memory load that otherwise comes with the thunks.
Those are the steps of my algorithm:
My first list contains between 2'000'000 and 4'000'000 words and has the type
[Text]
.I then run
parseSeries
on every word, a CPU-heavy algorithm of typeText -> Either ParseError [RawSteno]
. Because it's CPU-heavy, I run it concurrently. The result is collected in the strict list, which has less entries than the list of words from Step 1.Finally, the pairs
(Text, [RawSteno])
are folded for into a strict hashmap. It's not justHashMap.fromList
, because of some further logic where entries are checked for collisions with former entries. That same logic requires this step to be single-threaded again, which is fine given that it's not nearly as performance-heavy as Step 2.I don't see a reason to work with
vector
, when I really just need a foldable that is strict in the argument type. I do understand that I could work withvector
. Maybe someone can point out that I should.Btw, if all were single threaded, I would benefit from Haskell's laziness. Haskell could rush to step 3 for every word of Step 1. With concurrency I get a good speed-up but also the requirement to collect that strict foldable in Step 2 entirely before I can move on.
The text was updated successfully, but these errors were encountered: