[erlang-questions] Speed of CSV parsing: how to read 1M of lines in 1 second

Nicolas Dufour nicolas.dufour@REDACTED
Sun Mar 25 18:59:49 CEST 2012

Hello everybody,

While we are talking on csv parsers, I've been working on one for which the priority is not raw speed but to be able to parse huge files in a stream (if your csv is 60G big, no worry), or csv sent over any wire (http, whatever), and using a callback to both process each line and a general state for the whole parsing.

You can take a look at https://github.com/refuge/ecsv . It's actually based on a 3 states machine
The main goal was to be able to parse a stream and dispatch the processing across many processes.
So far it's able to parse double-quoted field and different delimiters and is written in 100% erlang.

The last benchmark I did though was showing something like 1700 row/s ( example here http://friendpaste.com/58s9VAVswaczu4Zav49GEq ).
But again, my goal was to withstand bug files through a stream.

Feel free to take a look at it.

Thank you,

Nicolas Dufour

On Mar 25, 2012, at 10:52 AM, Tim Watson wrote:

> Thanks for posting this detail Dmitry, it's very helpful. I'm going to
> recompile with +native and give it a go. I also note that you're not
> dealing with nested delimiters (e.g., where a field is enclosed in
> single or double "quotation marks" and can therefore contain the
> delimiters). If I can get the speed up to what you're seeing, then I
> might just send you a couple of pull requests. :)
> Also I'm interested to know how you called the csv:parse/3 function
> (or pparse instead) for these examples? Are you, for example,
> accumulating the results, or are you just counting the occurrences?
> Please let me know so I can replicate the same setup and test +native
> for myself.
> Also would you be kind enough to let us all know what kind of hardware
> your mac mini has, especially in terms of CPU and available memory?
> All in all, if we can clear up the differences I think parsing 300k in
> just under a second without having to resort to a NIF is a very good
> result and makes this the fastest csv parsing facility we've seen so
> far!!!
> On 25 March 2012 11:09, Dmitry Kolesnikov <dmkolesnikov@REDACTED> wrote:
>> Hello,
>> 1. Yes, I'd like to admit that I've missed the example file from the beginning of thread. I've put my sets generators into the repository. You can use them like this:
>> sh ./priv/dset line-ex.txt 1000 > ./priv/set-1M-ex.txt
>> The first parameter is line, second is kilolines to generate. line-16/48 are my original examples, line-ex.txt is from original example.
>> 2. I am a bit of curious why we are getting results of different magnitude, especially with Robert's run. My HW config is pretty close. So, I've build Erlang R15B from sources with following config:
>> ./configure --prefix=/usr/local/otp-R15B --enable-threads --enable-smp-support --enable-kernel-poll --enable-sctp --enable-hipe --disable-dynamic-ssl-lib --enable-darwin-64bit --enable-m64-build --without-javac
>> 3. I've re-run cases again with/without +native flag results are very interesting, so we can parse 300K lines in less then second, less the second for 1M rows is challenging:
>> Parse time of data set is 300K:
>> set-300K-16     653 ms / 2.18 us per line
>> set-300K-48   1832 ms / 6.11 us per line
>> set-300K-ex   2561 ms / 8.54 us per line
>> Parse time of data set is 300K +native:
>> set-300K-16     277 ms / 0.92 us per line
>> set-300K-48     672 ms / 2.24 us per line
>> set-300K-ex     925 ms / 3.09 us per line
>> Parse time of data set is 1M:
>> set-300K-16   4406 ms / 2.20 us per line
>> set-300K-48   6076 ms / 6.08 us per line
>> set-300K-ex   8670 ms / 8.67 us per line
>> Parse time of data set is 1M +native:
>> set-300K-16    1908 ms / 0.95 us per line
>> set-300K-48    2293 ms / 2.29 us per line
>> set-300K-ex    3119 ms / 3.12 us per line
>> 4. It might be unfair to comment but I have a good feeling that Max is evaluating/challenging a type of trade system ;-) Otherwise, why you have such hard latency requirements and dataset looks like a price snapshot ;-) IMHO, 2 - 4 us parse time per row is acceptable for "normal" web app.
>> Regards, Dmitry
>> On Mar 25, 2012, at 5:57 AM, Tim Watson wrote:
>>> On 25 Mar 2012, at 03:54, Tim Watson wrote:
>>>> Please also do run this code on some other (faster) machines to see how much of the slowness is specific to my machine.
>>> Oh and can you please pass on the set and set2 text files so I can test them on my machine to baseline the comparative differences between our environments?
>>> Cheers!
>>> Tim
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120325/2705af4b/attachment.htm>

More information about the erlang-questions mailing list