CharlesO
I have read through this thread: binary-pattern-matching-when-input-is-a-stream on a related subject, but i’m not able to make any headway.
I get this error trying to load and parse a large binary directly:
iex> JQL.save "--1566364097905", "STMT.ENTRY"
eheap_alloc: Cannot allocate 18446744071692551144 bytes of memory (of type "heap").
Crash dump is being written to: erl_crash.dump...
I’m doing an ETL (extract - transform - load) for a reporting project, moving data from a proprietary platform into SQL Server for easier reporting.
The parser has worked fine until I hit this size issue.
Please how / can we use streams to handle these kind of situations?
(particularly when initial or existing parser had not been built with streaming in mind)
JQL Parser: https://gist.github.com/CharlesOkwuagwu/4c6c89d96db7876bc0d27fecd518340e (updated)
Sample large file (~850mb unzipped): https://paperlesssolutionsltd.com.ng/java/--1566364097905.7z
Thanks.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 14 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
CharlesO
Found a really simple way to solve this. Just read the data-header, then parse row by row:
benwilson512
You can do this, you just have to write it body recursive instead of tail recursive.
CharlesO
Thanks for this. This is recursion 101, i know but i felt the size of each row was small enough to accumulate the parsed items left - right, as they occur in the data packet. The place i’ve really goofed is here:
on this line:
i’m practically saying split the 850mb blob of data (2.5m+ rows), and build a list out of it … all at once in memory
When i run same routine for 5, 100 or even 100,000 rows it complete without issues.
I need a way to process and discard each row and not accumulate to lists like i’m doing, like you guys have rightly pointed out, more so
NOTusing++to accumulateCharlesO
JQL is not so tricky. You can see the core repeating pattern above:
benwilson512
@CharlesO At a minimum if you are going to parse it all in memory, you need to never append to a list in a loop. This is an O(n^2) operation. You should prepend to the list, and then reverse at the end. Or, use a body recursive function that builds the list front to back via recursion.
CharlesO
I see your point.
The mistake might be in trying to build out / parse the entire file into memory in one go.
What you pointed out should not be an issue, say if i was processing each row of data and dumping row by row in the database, instead of parsing all rows first., before dumping to the DB, like i do now.
CharlesO
@NobbZ i just uploaded a 3k sample that contains 5 rows of data.
IF i can optimize the way i handle this, possibly the much larger file may equally be processed without memory issues
NobbZ
Another problem might be, that you are appending to your accumulator all the time… This requires rebuilding the list all the time, eg:
I’m not sure how to refactor though. As I currently will not try to understand the full parser, as I do not know JQL anyway…
CharlesO
That line was just for testing something else. removing it still brings allocation errors, but smaller:
i’m able to read the file, but not parse it.
This is a smaller sample of using the parser to handle just a few kilobytes:
def decode(hex), do: _r(Base.decode16!(hex))NobbZ
Does the problem persist if you remove this line?
https://gist.github.com/CharlesOkwuagwu/4c6c89d96db7876bc0d27fecd518340e#file-jql-ex-L102
You are not even using the result of
term_to_binary… And unless compressed, it will always require more memory than the input.