<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 11:18 AM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Apr 30, 2012 at 10:13 PM, Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:<br>

><br>
> I suppose you could implement it in pure erlang without creating any<br>
> intermediate lists, maybe it's even fast with HIPE. Floats are likely<br>
> another story.<br>
><br>
<br>
</div>It also creates lots of intermediate objects and we both know how<br>
"fast" erlang arithmetic is.<br>
<br>
Floats can be parsed in the same way.<br>
<br>
In fact parsing in C can be done in the way, you have described. And<br>
it is many times faster, according to my benchmarks, done while<br>
working with CSV.<br>
<br>
You should remember that intermediate objects lead to useless GC.<br>
</blockquote></div><br></div><div class="gmail_extra">Well, when numbers are small enough (60 or 28 bits depending on if it's full word 64-bit or not, see ./erts/emulator/beam/erl_term.h) they are stored as immediate fixnums, and the match context shouldn't have much overhead either. I have no doubt that it's significantly slower than good C code, but maybe it's better than the combination of binary_to_list/1 and list_to_integer/1 BIFs.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-bob</div><div class="gmail_extra"><br></div>