Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runGetState uses toChunks and fromChunks #23

Closed
kolmodin opened this issue Feb 13, 2013 · 2 comments
Closed

runGetState uses toChunks and fromChunks #23

kolmodin opened this issue Feb 13, 2013 · 2 comments
Assignees

Comments

@kolmodin
Copy link
Owner

This quickly gets expensive if called multiple times, and can build up a huge stack if called multiple times, like so:

countTrades :: BL.ByteString -> Int
countTrades input = stepper (0, input) where
  stepper (!count, !buffer)
    | BL.null buffer = count
    | otherwise      =
        let (trade, rest, _) = runGetState getTrade buffer 0
        in stepper (count+1, rest)

Code from http://stackoverflow.com/questions/9567040/poor-performance-parsing-binary-file-in-haskell/9573661#9573661

@ghost ghost assigned kolmodin Feb 13, 2013
@tibbe
Copy link
Collaborator

tibbe commented Feb 13, 2013

Why does this build up a huge stack?

kolmodin added a commit that referenced this issue Feb 13, 2013
Issue #23. Needs to be done for more functions in this module.
@kolmodin
Copy link
Owner Author

runGetState takes the Lazy ByteString, and turns it into a list of chunks.
The leftover data that did not get consumed gets converted back into a Lazy ByteString. When that happens, empty chunks gets filtered out. The filter is not strict though.
When this gets repeated many times, there are lots of filters applied to the same lazy bytestring. These multiple filters can eat the whole stack.
The patch above solves it, but needs to be used for more functions in the module before we close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants