<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 2, 2017 at 5:22 PM Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@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">HTTP client over external port is the most expensive way in all terms:</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>1) programming. It is REALLY hard to debug it.  Was it launched under valgrind? If no, then there are at least 5 horrible memory leaks and memory corruptions per each screen of code that haven't been discovered yet</div></div></blockquote><div><br></div><div>And yet you wrote <a href="https://github.com/maxlapshin/csv_reader">https://github.com/maxlapshin/csv_reader</a> (which I use btw). Running port executables protects the VM from any bugs in the C code, at least. It's almost like Erlang in that regard! Valgrind was used during Katipo's development.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2) deploying. Deploying NIF is a pain because you need to have build farm for each architecture that you target to.  For example, we deploy flussonic under suse 10, debian 7, debian8/ubuntu16, arm7, arm8, windows, elbrus 2k.   All these platforms are different and you cannot rely on cross compiler. Good luck with building repeatable infrastructure for compiling under windows.</div><div><br></div><div>If you have erlang code, you can compile under mac and launch under windows because guys from OTP team have already done all dirty job. Just read their manual and follow it.</div></div></blockquote><div><br></div><div>This I will concede can be an issue with NIFs. It's not an issue for my use case, however, and can be overcome by using things like Docker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>3) speed. It will be slow in all terms. High latency due to multiple OS process scheduling: read in one process, then write to pipe and send further.  Do you think that linux pipe is a "good and optimized" thing? It is not.</div><div>What if we speak about high traffic?  1 gigabit of input will become several gigabits of _useless_ copying data.</div></div></blockquote><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><br></div><div>So I do not understand what can give libcurl that cannot be achieved in plain erlang.  It is definitely not about high traffic speed because plain vanilla lhttpc can download 10 Gbit/s over fiber without any extra modifications.</div><div><br></div></div></blockquote><div><br></div><div>I think perhaps you have tunnel vision based on your specific HTTP use case. I'm not sure what you mean by "in all terms". In <a href="https://github.com/lpgauth/httpc_bench">https://github.com/lpgauth/httpc_bench</a> (d)lhttpc peaks at 93178 reqs/s whereas Katipo peaks at 107900. You may not require the HTTP compatibility that *22K* commits to libcurl provides. Your custom version of lhttpc may well be able to sustain 10Gbit/s over fiber - that is not my use case so I've no idea if Katipo could do the same.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 31, 2017 at 10:22 AM, Paul Oliver <span dir="ltr"><<a href="mailto:puzza007@gmail.com" target="_blank">puzza007@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 dir="ltr"><span><div class="gmail_quote"><div dir="ltr">On Thu, Aug 31, 2017 at 6:20 PM Taras Halturin <<a href="mailto:halturin@gmail.com" target="_blank">halturin@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">I think, Max means that you choose most expensive way to deal with it and it's not about efficiency of http handling but about efficiency of aim achieving :)</div><div class="gmail_extra"><br></div></blockquote><div><br></div></div></span><div dir="ltr"><div dir="ltr"><div class="gmail_quote">The most expensive way in terms of what? If not speed do you mean development effort? Given that the aim is to use libcurl then the choice is a port executable or some sort of NIF. When using a port executable I don't have to worry about it crashing my VM and all I pay is the price of port communications. If I use a NIF I have to concern myself with making sure my NIF code and the code in libcurl doesn't crash my VM. That's a lot more development time and risk.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Paul.</div></div></div></div>
</blockquote></div><br></div>
</blockquote></div></div>