<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 25, 2016 at 6:50 PM zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016年3月25日 金曜日 17:08:49 Benoit Chesneau wrote:<br>
> Hi all,<br>
><br>
> I have a large data file provided as comma separated values (unicode data)<br>
> I need to load and parse it ASAP since it will be used by all the<br>
> functions.<br>
<br>
...snip...<br>
<br>
> Is there anything else I can do?  I am curious how others are doing in that<br>
> case.<br>
<br>
Does it all need to be in memory all the time?<br>
<br>
Based on whether or not this is true and the context of use, I opt for<br>
<br>
- generate a smaller, more Erlangish version of the dataset<br>
  (what you're doing with DETS, for example)<br>
- load it into a database that is a common resource<br>
  (not always an option)<br>
- write a routine that makes smarter use of file reads than loading<br>
  everything at once -- this can be surprisingly fast, even in Erlang,<br>
  and be made to utilize a fixed amount of memory<br>
  (but is not always a good fit for the problem)<br>
<br>
But use-case drives everything.<br>
<br>
Honestly, you're one of the guys I tend to grep posts from when looking for<br>
answers to my own questions, so I reckon my ideas above are things you have<br>
already considered.<br>
<br>
Also, with regard to datasets in general, if there is any way to rule out<br>
any of the data on load, a combination of a filter + a constant memory<br>
read-in can be a big win if you do need it all in memory, but have some<br>
criteria by which the data you need all at once can be reduced (again,<br>
though, not always the case).<br>
<br>
-Craig<br></blockquote><div><br></div><div><br></div><div>Heh, thanks :)</div><div><br></div><div> DETS sounds a good idea. I didn't try it yet. Doing it now.</div><div><br></div><div>In the mean time I tried another idea i still need to test on different platforms: </div><div><br></div><div>- I build the beam first and place it in priv dir</div><div>- when the application is loaded, I load the beam in memory using `code:load_binary/3` </div><div><br></div><div>The code is here:</div><div><a href="https://github.com/benoitc/erlang-idna/tree/precompile">https://github.com/benoitc/erlang-idna/tree/precompile</a><br></div><div><br></div><div>The beam is generated using a simple shell file for now: </div><div><a href="https://github.com/benoitc/erlang-idna/blob/precompile/mkdata.sh">https://github.com/benoitc/erlang-idna/blob/precompile/mkdata.sh</a><br></div><div><br></div><div>and loaded here:</div><div><a href="https://github.com/benoitc/erlang-idna/blob/precompile/src/idna_unicode.erl#L3">https://github.com/benoitc/erlang-idna/blob/precompile/src/idna_unicode.erl#L3</a><br></div><div><a href="https://github.com/benoitc/erlang-idna/blob/precompile/src/idna_unicode.erl#L216-L226">https://github.com/benoitc/erlang-idna/blob/precompile/src/idna_unicode.erl#L216-L226</a><br></div><div><br></div><div>Tests pass. Right now the only annoying thing with it is the need to also include that separated beam file when you escriptize but I guess I can live with it. </div><div><br></div><div>I also need to check what is the impact of using such trick when you need to upgrade the application (ie how is handle the -on_load attribute). Maybe I don't need that. Just copying the beam to the correct ebin dir should be enough. Doing it for all build tools around (<a href="http://erlang.mk">erlang.mk</a>, rebar3, rebar, ..) makes it had though.</div><div><br></div><div>Thoughts?</div><div><br></div><div>- benoit</div></div></div>