# 编辑器 * [IDEA](https://www.jetbrains.com/idea/) * [VIM](https://www.vim.org/) * [VSCode](https://code.visualstudio.com/) * [ Sublime Text 3](http://www.sublimetext.com/) * side-effect-free无副作用,其中一种定义是说:一个程序执行前后保持程序的状态不变,不改变非局部变量的值,不改变传入参数值,也无I/O 1，单进程问题 Erlang虚拟机属于抢占式调度，抢占式调度有很多好处，但是同样也存在这弊端。虚拟机在默认情况下分配个每个进程的资源都是相同的，但是若一个进程（gen_server/event/fsm）要为其他许多进程提供服务，这个进程就极有可能成为整个Erlang系统的瓶颈所在。http://www.cnblogs.com/--00/p/4277640.html 2，列表解析效率 在Erlang编程语言中，list/string 是非常常见的一种数据类型，list处理的方式几乎都是遍历或者是尾递归，在list规模小的情况下，这种方式几乎不会给大家造成麻烦，但是一旦list的规模很大之后，情况就会变得非常糟糕。如list的“++”操作存在陷阱，erlang:length(List) 存在陷阱，queue:len(Queue)存在陷阱，诸如这种陷阱看起来很细碎，但是如果不好好处理，指不定就容易出现各种让我们摸不着头脑的坑。 前不久，我们刚刚在一个系统中，优化了一个lists:keydelete/3 的操作，大幅度提升了整个接口处理的速度。 当然，这些问题和erts的设计思路有很大的关系，如：private heap，变量不变 ... 。 3，refc binary binary的存在在一定程度上缓解了list处理带来的“低效率”的问题，但是，refc binary（erlang:byte_size(Binary) > 64的binary）的gc又让人比较蛋疼。Erlang process structure -- refc binary 4，OOM 在一定程度上，这也是单进程问题的一个附属品。单进程获得虚拟机资源有限，处理性能不足，导致message mail box 的message不断挤压，继而引发large heap，导致整个Erlang 虚拟机crash。最最典型的就是lager了。 5，Erlang进程CPU消耗度量 一直以来，大家都在社区中试图寻找度量单个Erlang进程CPU的消耗，但是不管是Erlang现在的API函数，还是社区中的方案，都没有提供一种行之有效的方案。为什么？我简单摘抄一段Erlang_IN_Anger中的一段描述吧： > It is generally difficult to properly analyze the CPU usage of an Erlang node to pin problems to a specific piece of code. With everything concurrent and in a virtual machine, there is no guarantee you will find out if a specific process, driver, your own Erlang code, NIFs you may have installed, or some third-party library is eating up all your processing power.