<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">>These two assumptions are basically the most challenging issues stop people from getting more performance<div><br></div><div>I guess so, that is why I've decided to introduce it. Actually this design was inspired by my job task. I'm working on graph processing library written in Scala, which stores large amount of data in of-heap memory in binary format. I want to read this data. Storable is not good enough because there is a variable-length data types as well. On other hand all always available loaded in memory and no incremental parsing required. </div><div><br></div><div>So, my approach is something between Storable and fully featured serializes such as binary/cereal. </div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ср, 20 мар. 2019 г. в 09:20, Dr.Koster <<a href="mailto:drkoster@qq.com">drkoster@qq.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>These two assumptions are basically the most challenging issues stop people from getting more performance, e.g. If somehow you want to support incremental parsing, a primitive like `ensureN` probably need to do something like</div><div><div><br></div><div>```</div><div>ensureN n = Parser $ \ buf ... k -> </div><div> if n < length buf then k buf ...</div><div> else partial buf ... k</div><div>```</div><div><br></div><div>The k appear twice inside `ensureN` 's both branch, which will stop parsers from getting inline sooner or later since inlining k into both branch will produce exponential amount of code, so instead GHC will allocate k and make a jump, the best we can get is probably to try make it a joint point, so no allocation is needed, but that's the best you can get from argument passing buffers.</div><div><br></div><div>Regards</div><div>Han Dong</div><div><div><br></div><div><br></div><div style="font-size:12px;font-family:"Arial Narrow";padding:2px 0px">------------------ 原始邮件 ------------------</div><div style="font-size:12px;background:rgb(239,239,239);padding:8px"><div><b>发件人:</b> "Joachim Durchholz"<<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>>;</div><div><b>发送时间:</b> 2019年3月20日(星期三) 中午1:28</div><div><b>收件人:</b> "haskell-cafe"<<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>>;</div><div></div><div><b>主题:</b> Re: [Haskell-cafe] Yet another binary reader (10x faster thanHackage's binary; )</div></div><div><br></div>Am 19.03.19 um 22:58 schrieb Станислав Черничкин:<br>> possibly because of inlining of <br>> specialization magic.<br><br>I have seen people validate this kind of assumption, by looking at the <br>various intermediate representations of code.<br>If you're after performance, you may want to do that. You may find that <br>things work differently than expected, with the potential for becoming a <br>bottleneck when stuff is scaled up (more varied datatypes in the input <br>stream, or more complex target datatypes, stuff hidden behind "oh I <br>don't need GC yet", that kind of finding).<br><br>Regards,<br>Jo<br>_______________________________________________<br>Haskell-Cafe mailing list<br>To (un)subscribe, modify options or view archives go to:<br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>Only members subscribed via the mailman list are allowed to post.</div></div>_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="font-family:arial;font-size:small">Sincerely, Stanislav Chernichkin.</span><br></div></div>