<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Mar 25, 2016 at 12:09 PM Benoit Chesneau <<a href="mailto:bchesneau@gmail.com">bchesneau@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I have a large data file provided as comma separated values (unicode data) I need to load and parse it ASAP since it will be used by all the functions. </div></div></blockquote><div><br></div><div>What's the interface?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The current implementation consists in parsing the file and generate either a source file or an include file that will be then compiled. My issue with it for now is that the compilation will use more than 1GB and then crash on small machines or containers.</div><div><br></div><div>Other solutions I tried:</div><div><br></div><div>- use merl + `-onload` to build a module on first call of the module (too long the first time)</div><div>- store an ets file and load it later, which can be an issue if you need to create an escript will all modules later</div><div>- load an parse in a gen_server (same result as using merl)</div><div><br></div><div>Thinks I have in mind:</div><div><br></div><div>- generate a DETS file or small binary tree on disk and cache the content on demand</div><div>- generate a beam and ship it</div><div><br></div><div>Is there anything else I can do?  I am curious how others are doing in that case. </div></div></blockquote><div><br></div><div>I think this depends entirely on your interface :)</div><div><br></div><div>Do you have to scan the entire table? If so why? If not, why not treat this as a indexing problem and start from disk, assuming you can defer loading of any data until it's read?</div></div></div>