月度归档:2011年03月

XML解析中DOM和SAX的比较和选择

在前面的文章 <<PHP中的XML解析的5种方法>> 中以功能实现为维度实现了XML的解析。 今天我们从另外的维度说说XML解析的两种方式。 一般来说,在PHP中,XML的解析包括DOM,SAX,正则表达式等常规方式。 特别是前面的两种,不管是在PHP中还是在Java等语言中都有使用。

DOM解析器

DOM 是具有平台和语言无关性。它是表示 XML 文档的官方 W3C 标准。 DOM解析器在实现方式是预加载整个文档,并把XML文档转化为一个包含其内容的树。 这个树结构方便开发人员在其中寻找特定信息,并可以调用树的一些操作很容易的添加和修改树中的元素。

在PHP中,它在形式上是基于对象的存储,然而在本质上是存储在一堆结构体中, 在对象与对象的之间是以一种类似于父子的概念关系存在,从而在整体上构成了一个树的结构。

由于DOM解析器是预加载的,所以整个文档的结构在内存中是持久存在的。因此可以在其生命周期中随时修改它,以便应用程序能对数据和结构作出更改。 它还可以在任何时候在整个树结构中上下导航,并且DOM解析器使用起来比较简单。 但是,同样因为是预加载的方式,需要处理整个 XML 文档,所以对性能和内存的要求比较高。 当遇到特别大的文档时,解析和加载整个文档可能会很慢且很耗资源, 此时我们就需要另外一种方式,比如一边读取一边处理,又或者类似于SAX基于事件的模型。

在PHP中使用DOM解析器是基于DOMDocument类来实现。具体的实现请移步之前的文章: <<PHP中的XML解析的5种方法>>

SAX解析器

SAX是simple API for XML的简写,与DOM不同,它并不进行预加载操作,而是一边扫描文档,一边解析。 SAX解析器 采用了基于事件的模型,它在解析 XML 文档的时候可以触发一系列的事件, 当发现给定的tag的时候,它可以激活一个回调函数,告诉该函数指定的标签已经找到。 SAX解析器 对内存的要求通常会比较低,因为它让开发人员自己来决定所要处理的tag。 特别是当开发人员只需要处理文档中所包含的部分数据时,SAX解析器 这种扩展能力得到了更好的体现。 但用 SAX 解析器的时候编码工作会比较困难,而且很难同时访问同一个文档中的多处不同数据。    看一个PHP中使用SAX解析器的例子。我们使用Google天气API的XML文档。

API地址:http://www.google.com/ig/api?weather=shenzhen

<?php
/**
 * 简单的Google天气SAX解析器
 * 解析http://www.google.com/ig/api?weather=shenzhen中将来几天的天所情况
 */
class weatherSaxParser {

    private $_parser;
    private $_xmlData;
    /**
     * 当前的Tag
     * @var <type>
     */
    private $_tag;
    private $_weather;
    /**
     * 保存天气的数组的key
     * @var <type>
     */
    private $_key;
    private $_attributes;
    /**
     *需要解析的标签集合
     * @var <type>
     */
    private $_parseTags = array('low', 'day_of_week', 'high', 'condition');

    public function __construct() {
        $this->_key = 0;
        $this->_parser = xml_parser_create();

        xml_set_object($this->_parser, $this);
        xml_set_element_handler($this->_parser, 'tagStart', 'tagEnd');
        xml_set_character_data_handler($this->_parser, 'tagContent');
    }

    public function setXmlData($xml) {
        $this->_xmlData = $xml;
    }

    /**
     * 执行解析操作
     */
    public function run() {
        xml_parse($this->_parser, $this->_xmlData);
    }

    /**
     * 标签开始回调函数
     * @param <type> $parser
     * @param <type> $tagName
     * @param <type> $attributes
     */
    public function tagStart($parser, $tagName, $attributes = NULL ) {
        $this->_tag = strtolower($tagName);
        $this->_attributes = $attributes;

        if ($this->_tag == 'forecast_conditions') {
            $item = array();
            $this->_weather[$this->_key] = $item;
            $this->_key++;
        }

        if ($this->checkTag()) {
            if (empty($this->_weather[$this->_key - 1][$this->_tag])) {
                $this->_weather[$this->_key - 1][$this->_tag] = $this->_attributes['DATA'];
            }
        }
    }

    public function tagEnd($parser, $tagName ) {

        $this->_tag = NULL;
        $htis->_attributes = NULL;
    }

    public function tagContent($parser, $content ) {

        if ($this->checkTag()) {
            $this->_weather[$this->_key - 1][$this->_tag] = $content;
        }
    }

    public function __destruct() {
        xml_parser_free($this->_parser);
    }

    public function checkTag() {
        return in_array($this->_tag, $this->_parseTags) && $this->_key > 0;
    }

    public function getWeather() {
        return $this->_weather;
    }

}

$fp = fopen('weather.xml', 'r');

$saxParser = new weatherSaxParser();

while ($data = fread($fp, 4096)) {
    $saxParser->setXmlData($data);
    $saxParser->run();
}

print_r($saxParser->getWeather());

unset($saxParser);

以上针对XML文档中’low’, ‘day_of_week’, ‘high’, ‘condition’, ‘forecast_conditions’等标签进行处理。 在SAX解析器中,对于文档的遍历也是依赖于文件的行读取操作。

从上面的例子我们也可以看出SAX解析器的一些缺点:

  • SAX解释器不允许对XML文件随机存取,只能顺序读取
  • SAX解释器中元素之间的遍历困难,在多个标签间移动比较困难
  • SAX是解析一个节点后回调一个方法,把该节点相关信息传送个调用者,然后丢弃这些信息,继续解析下一个节点。它不会预存储整个XML文档,也不会在解析后保存任何解析结果。
  • SAX的修改XML能力差

结论

DOM 采用建立树形结构的方式访问 XML 文档,它体现了预处理的编程优化思想。这对于一次获取多次查询或修改的情况较适用,并且DOM具有良好的接口定义,编程较方便,一般来说,选择DOM会舒服很多。 但是SAX也有其存在的理由,SAX 采用的事件模型,它体现了只取所需的优化思想。这对于只处理一次或数据量巨大导致无法预加载时有更好的性能。

DOM与SAX有点类似于PHP中读取文件操作file_get_contents和fopen/fread/feof的组合。 file_get_contents的使用比较方便,并且可以一次性将所有数据取出来,仅以后调用。 fopen/fread/feof组合操作则是打开文件可以一段一段的处理。而在SAX中可能也会调用fopen/fread/feof组合。

正所谓有得有失,重点在一个平衡和取舍,根据实际情况使用合适的技术。


参考资料

http://www.ibm.com/developerworks/cn/opensource/os-xmldomphp/      http://hannoi2009.blog.163.com/blog/static/12282842820097157152651/

PHP优化建议

这是在 Google Code 下的 “Let’s make the web faster” 网站中一篇名为 << PHP performance tips >>的文章。 这篇文章曾经引起PHP界的一些讨论,因为作者是Google的人。现在这篇文章做了一些修改。

  1. 优化代码瓶颈
  2. 升级PHP版本
  3. 使用缓存
  4. 使用输出缓冲
  5. 避免写那些傻傻的set和get方法
  6. 不要随意复制变量
  7. 不要在循环中使用SQL查询

下面我们详细说说这些优化建议:

1. 优化代码瓶颈

这是一个放之四海皆准的建议,对于代码优化来说,关键是找那些卡住了代码喉咙的那段代码,把瓶颈找到了,整个性能也许会有数据量级的提升。 或者换一个思路,优化那些执行次数多的代码,这里一点的优化可能给你惊喜。 代码瓶颈是什么呢?空间复杂度,时间复杂度,或者我们需要改变的是整个数据结构,或者我们最需要改变的是需求, 在某个不经意间,对于一些需求的把握不到位,可能会导致整个代码实现方案的低效率。

2. 升级PHP版本

这是是针对PHP版本的优化,新的换掉旧的,新的Zend引擎较旧的在速度上有较大的提升。

3. 使用缓存

缓存,作者建议我们使用Memecache或者使用支持缓存的模板引擎smarty。 缓存是什么?我理解中的缓存是指以一种更快的访问介质,或更近的距离,或更便捷的方式(省略一些中间过程,直接获取结果)实现数据等的访问。 对于PHP来说,除了作者建议的以外,可以考虑使用opcode缓存,跳过词法解析,语法解析和生成中间代码的过程。

4. 使用输出缓冲

作者的意思应该是避免缓冲太多的数据,尽早的将数据发送到客户端。

5. 避免写那些傻傻的set和get方法

这个是针对使用set和get方法存储和获取变量的方式。作者的建议是直接使用public成员变量,直接操作。 这点在面向对象的编程思想中是有一些问题的,但就效率来说,确实有提高。为什么呢?这个得从PHP中对象的结构说起。对象存储结构:

typedef struct _zend_object {
    zend_class_entry *ce;
    HashTable *properties;
    HashTable *guards; /* protects from __get/__set ... recursion */
} zend_object;

当操作对象的成员变量时,会直接操作HashTable *properties。而如果是使用自定义的get方法和set方法,则会以成员方法的方法调用。 而这些方法都会以一个函数存在。整个调用过程和函数调用一样。 而这些方法是用户自定义的方法,则会生成中间代码,执行这些函数就会执行这些中间代码,整个流程相对于直接操作变量有本质上的区别,性能当然也比不上了。

6. 不要随意复制变量

这点,曾经也被人诟病过,其实作者的观点是没有错的,只是不能依据这个标题来作判断,看其示例:

echo strip_tags($_POST['description']);

// 对比

$description = strip_tags($_POST['description']);
echo $description;

同样是输出处理过的$_POST['description']值。第二种方法较第一种方法多了一个变量。 这对于PHP生成的中间代码来说,这样多了一步赋值操作,也多了一个生成全局的变量$description的过程(假设代码是在全局范围内执行),从而在时间和空间上都会有一些浪费。 但是如果从另一个方面考虑:这个函数的返回值需要在后面多个地方用到,那么这里还是使用变量存放会好一些。

7. 不要在循环中使用SQL查询

这也是一个在其它语言中也同样适用的建议。把SQL放入循环中,天知道这个循环会执行多少次,每一次执行都会有一次数据库请求。 假设循环有一万次,想象一下,连续的一万次数据库查询。。。。 这样的问题经常会出现在面向对象的编程中,由于封装等问题,查询被封装在类中。从而导致一些不可见的查询操作被放到了循环中。 对于这种情况,可以考虑将需要的多次查询的数据一次取出,然后在循环中直接调用内存中的数据。

er结婚了,深入理解PHP内核(TIPI)项目第一阶段发布了

我们的朋友,TIPI团队成员,博客哥,er同学在今天这个春光灿烂,春暖花开,春心荡漾,春情澎湃的大好日子里,兴高采烈的走入了婚姻的殿堂。 在这样一个让人激动不已,激情四射,的日子,TIPI团队决定发布 深入理解PHP内核 项目的第一阶段成果。

大概在半年前,我们在网上相聚,莫名的邂逅,有了我们这样的一个团队。我们有激情,有想法,有行动,也有了我们这个项目。 开始的艰难,没有时间的痛苦,坚持,从而有了今天的发布。一路走来,有辛苦,也有收获,至少记录了我们的青春,至少做了我们想做的!

深入理解PHP内核(TIPI)项目是一个开源的,分析PHP内核的系列文章项目。整个项目是基于PHP5.3版本的源码。 它包括PHP语言中我们常用的变量,函数,类,对象等的实现原理,也包括PHP的虚拟机,内存管理机制,线程安全,错误异常,文件流和PHP5.3新增加的垃圾收集机制,命名空间等。 除了PHP语言本身的特性外,还包括PHP扩展的相关信息。我们希望这个项目可以帮助更多的PHPer可以更加了解PHP语言本身,知其然知其所以然!

第一阶段,我们发布了前四章,从环境的搭建,源码的阅读方式到对于PHP源码的整体把握,再到对于变量和函数的详细解说。随着项目的进展,我们本身对于PHP内核的理解也加深了许多。 后续我们将以章为单位发布后续的章节。现在第5章正在撰写…

在线阅读入口>>>

TIPI团队序

博客哥三者,今聚首于网络一隅,共谋TIPI大计,与诸君共享技术之事: 向来穷PHP内核之事者或多,却鲜有分享之举。哥三者,常流连于中外博客也,若得一佳作,即欣喜若狂,本乐分享,及有学习总结之心,欲为PHP内核之事穷全身之力。

  • reeze,博客哥者,好苹果,好开源, 陶醉于Web开发及架构, 为Ruby之美所折服, 甚爱iOS及其开发, 好一切善美之事物.
  • er,博客哥者,稀饭Linux, Web, 2.0, Ajax, C, PHP, Javascript, CSS等。乃一以代码为乐之码农也。
  • phppan,博客哥者,好书,好PHP,亲于PHP,C,Ajax,程序架构等

是以三人之力行分享之事,转GIT,习markdown,论项目之计于深夜,何怕事之不成?务使PHP内核之事向众人知。 为此特示。

项目大事记

  • 2010/12/28 14:47 pan向reeze提议写一个PHP内核系列文章,一拍即合.
  • 2010/12/28 15:10 er同学加入.组织正式形成.
  • 2010/12/30 11:11 pan发出<<深入理解PHP内核>>第一份完整目录草稿.
  • 2010/12/31 21:14 举行第一次三方会谈,结合pan和reeze的目录草稿确定了正式目录. 标志着TIPI团队项目的正式确立.. (鼓掌).
  • 2011/01/01 05:08 reeze向github版本库提交了完整的项目, TIPI项目开始进入实施阶段
  • 2011/01/06 15:22 经过哥三激烈的讨论后做出艰难的决定,我们的项目域名正式确定为php-internal.com.(撒花无数).
  • 2011/02/14 23:32 在这个几人欢喜几人愁,充满花香的日子里, 哥三在深夜确定了TIPI项目的第一次整体发布流程,并且定稿了前三章的大纲以及确定了发布前的调整工作。
  • 2011/02/25 02:53 虽然我们还没有正式开始推广TIPI, 但已经有人开始关注TIPI了. 恭喜icodeuhttp://blog.icodeu.com同学成为我们第一位留下脚印的同学(看留言时间,也是个夜猫子啊.)
  • 2011/03/10 11:22 经过TIPI团队的慎重考虑, TIPI团队新增一员大将:honestqiao同学, 欢迎他的加入!

特别鸣谢

我们需要感谢我们家里的领导,没有有她们的支持,也就没有我们今天的发布,感谢她们的包容,感谢她们的照顾,感谢她们的理解和支持。谢谢!