<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 21, 2015 at 9:45 AM, ruanbeihong <span dir="ltr"><<a href="mailto:ruanbeihong@gmail.com" target="_blank">ruanbeihong@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it's the last thing to think about when writing codes. You'd expect the compiler to do such 'update inline' optimization for you.</blockquote></div><br></div><div class="gmail_extra">It is a very true statement. But there are limits to what kind of transformations you can expect of a compiler. If you have used lists with lots of lists:keyreplace/4 for instance, then the compiler is not clever enough to transform this to a list comprehension, which turns an O(n^2) algorithm into a O(n) algorithm.<br><br></div><div class="gmail_extra">Also, there are limits to a functional programming language. In-place updates requires the compiler to prove that access to the data is truly linear. If you have lots of cross-module calls, the Erlang evaluation model somewhat constrains you, because if a module is loaded while the cross-module calls are being done, then you expect the code to jump to the new version. And the new version may use the data in a non-linear fashion.<br><br></div><div class="gmail_extra">Programming languages which support linear access for updates usually annotate access in a type/effect system (ATS, Rust comes to mind). And thus they have an easier time optimizing since they can rely on the program being well-typed or well-effected.<br><br></div><div class="gmail_extra">All of this said, functional languages commonly have GCs which are extremely good at handling high allocation rates. Non-live data on the heap has 0 reclamation cost in the Erlang BEAM VMs GC for instance. The primary problem here is the memory bottleneck in modern CPUs: papers from the 90'es show that usually, memory is less of an issue than first thought. But here, 20 years later, it is about time to redo those old findings.<br><br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>