内存池技术其实这是服务端编程中很常见。使用内存池技术可以有效地避免频繁的内存申请/释放操作，在内存池技术中，内存释放时实际上并没有通知操作系统真实的释放和回收，而仅仅是对将要释放的内存做个了标记，表示该部分内存已经不再使用。等下一次申请内存时，就从这些“可用”的内存链表中取出一个内存块，从而避免了频繁的内存申请/释放操作，大大节省了系统资源。根据测试和统计，在 PHP 4.4版本中，一个典型的较为简单的请求就有超过 20,000次的对系统堆的申请和释放操作，这花费的时间相当于整个脚本所花费时间的 20% 左右。由此可见，若能降低这种资源消耗则效果是极为可观的。
与此同时，采用内存池技术也带来一个更为重要的“副作用”：避免了大量的“内存碎片”。一般情况下，内存碎片是对系统没有多大影响的，但服务端应用明显不同于一般应用，服务端会面临很高数量级的访问请求，这些请求也伴随着更高数量级的内存申请/释放操作。内存碎片过多将导致内存利用率降低，降低内存分配速度，严重时还会触发内存分配失败，尽管此时理论上仍有可分配的物理内存。
最后，内存池技术还有一个不太引人注意的好处：它能降低内存泄漏的概率。因为实际申请的内存块虽然尺寸较大，但数量较少，而且一般情况下都是统一申请，实际释放时也可以统一释放。显然，这比代码中即时申请，而没有即时释放所造成内存泄漏的概率要小很多。
不过采用内存池技术的管理器也明显要比常规管理器（指的是内存即时申请，即时释放的管理机制）的内存开销要大，因为除了真正申请的内存外，管理器还得负责维护每个内存块的状态，因此 PHP 5.2 中把 php.ini中 memory_limit 指令值从默认的 8M 提升为 16M 。这看似增加了内存消耗，并且也需要极少量的CPU资源来管理，但由于内存碎片的减少实际上并没有增加多少消耗，再结合其他方面的表现，可以说是所得远大于所失，尤其是在高负载情况下。
3、PHP 5.2 也对 INI 指令的存取方面做了优化。
PHPer 都知道，在 PHP 脚本中我们可以用 ini_set() 函数动态改变某个 PHP 指令的值。但问题是在请求结束后你还得把这些改变的值给恢复过来以保证下个脚本能正确使用。在 PHP 5.2 之前，PHP 的做法可谓是不辞劳苦，逐个遍历 INI 指令并恢复的。如果你是整个脚本都是 ini_set() 也就罢了（当然这个情况也是极其罕见的。：）），万一我的脚本中很少使用甚至根本就没有使用这个函数那我不就是亏大了？因此 PHP 5.2 为了解决这个问题又额外增加了一个表专门保存更改过的指令，这样就不用来回挨个恢复了。
4、PHP 5.2 还对 require_once() 和 include_once() 两个函数进行了优化。
PHP 5.2 以前 require_once() 和 include_once() 的做法是无论某个文件是否已经被缓存或编译过，统统是先 fopen() 再说，打开成功后在查询一下是否已经缓存过。这么处理的原因就是 在 PHP 5.1 以前没有很完美的解决 realpath() 相对路径和符号连接方面的问题。因为若不能唯一地正确地确定某个路径的真实路径表示那么你就无法利用这个路径的唯一性去解决某个问题。而 fopen 则没有这个顾虑。realpath() 的这个问题在 PHP 5.1 中被彻底搞定了，但还没来得及应用到 require_once() 和 include_once() ，结果就拖迟到现在。解决这个问题的好处是在于避免了 fopen 这个 I/O 操作，在很多高负载情形中，通常都是 数据库、网络或者磁盘 I/O 而不是 CPU 成为瓶颈。
5、对HashTable 的复制也进行了优化。
HashTable在ZendEngine是一个很基本的数据结构，数组本质上就是一个 HashTable。对HashTable 的优化也将意味着对数组的复制操作（无论是显式还是隐式）速度将会有一定的提升。
6、其他的一些性能方面的改进。
PHP 5.2 也对在FastCGI SAPI 模块中访问环境变量的性能做了少许优化。以前则是逐行搜索，现在则是通过 Hash 值来存取。除此之外，PHP 5.2还对str_replace() 和 implode() 函数以及“try {} catch {}”块等都做了一定的优化。 下面是对一些语言特性和安全特性方面的改进：
