Bill 这个老家伙，这么多天，才指派了 issue 过来。

这个 charset 应该放在 config 的什么部分？

我个人倾向于跟 $config['port'] 一样，直接放在 config 数组中： $config['charset']。实际上之前的修改也是这么做的。

但是还有一个选择是放在 $config['options']['charset']。这样肯定更符合老外的胃口，他们很少用 charset 这个东东的。

Bill 发邮件说他想放到 $config['driver-options']['charset']，我是严重的不同意。这个肯定不是数据库特性的东西，而应该是跟 port 一样是每个数据库不同，但是每个都可以设置的东西。

恩，考虑考虑先～～反正无论如何，我不同意放到 driver-options 里去设置 charset。

在分析 Zend_Config 的代码的时候，感觉 Ini.php 和 Xml.php 中代码差异非常大。那么性能上是否有一个确定的优劣？于是做了以下比较和分析。

先看一下两个类在加载配置文件上的差异：

Ini 使用的是 parse_ini_file 这个内置函数。在我使用 xdebug 中记录的性能测试中，这个内置函数的运行时间可以忽略不计，可以说执行速度相当快。

Xml 使用的是 simplexml_load_file 这个内置函数，由于 xml 本身的众所周知的原因，这个函数的执行非常耗时，平均大约需要 0.3 ms。

这么乍一看，好像是 Ini 的性能更加优秀一些。且慢，请继续看。

Ini 虽然在加载配置文件上非常占优势，但是由于 Ini 文件本身不是分层记录。而 Zend Framework 利用分隔符（默认是“.”）定义了 Ini 文件的分层关系。这就是说在配置文件加载后，仍然需要对加载的数组进行解析。Zend Framework 中使用的是解析后迭代 Zend_Config 类的构造函数的方法。逐个解析读取的数组元素，然后使用 Zend_Config::__construct() 进行迭代处理。最后构造出完整的配置数据对象。

Xml 则容易许多，由于 simplexml_load_file 加载后就是完整的有层次关系的数组。这样在迭代 Zend_Config::__construct() 构造配置数据对象时就省略的复杂的解析层次关系这一步。虽然 simplexml_load_file 自身执行时间很长，但是它已经解决了后面的许多工作。

所以结论呢，Xml 性能上更优秀一些？

错！

对于只有一层的配置文件，由于没有复杂的层级处理 Ini 显然更加快速。

而对于复杂的、有众多继承关系的配置文件来说 Xml 是不二选择。

不过我想，对于多数应用，为了更好的管理配置文件，恐怕都使用了大量的层级来区分不同的配置模块。比如在 ninny 项目中，数据库、缓存、会话、模块等等都不是单层次的配置。所以我将其改进为 Xml 配置文件，以提升那 7 ms 的性能。*_*!

本想针对 Zend_Config 做一次全面的行级代码分析，不过第一没时间，第二代码量太大，实在麻烦，所有就用本文做个对 Zend_Config 的了结吧。