加快Flex应用启动速度的5种方式

Posted by dengwei

Jun Heider在O’Reilly的InsideRIA站点上发表了一篇精彩的文章，该文章就如何加快Flex应用的启动速度提出了很多建议，以帮助用户减少看见讨厌的“Loading”对话框的出现时间。他深入探讨了问题的不同方面，并对每种技术的优势和劣势进行了评判。

从外部加载媒体（Media）
Heider提到了一个常用的Flex最佳实践——限制嵌入到应用/SWF文件中的媒体的数量，如图像、影片及mp3等资源都可以从外部的SWF文件加载。 Flex框架可以直接将图片、mp3及字体等资源编译到SWF中。当你想让最终用户获得全部资源时，这种方式确实能派上用场，但是这会导致你的应用长时间停留在“Loading”阶段。中国最大的RIA分享社区-与中国闪客一起成长和发展！

在嵌入式字体中限制字符集
Heider建议在嵌入式字体中限制字符集以降低SWF文件的总下载时间： 当你在Flex中嵌入一种字体时，你就会获得该字体的全部字符的支持。尽管这可能是你想要的，但你确信你需要全部字符么？例如，在一个只面向英文的应用中，你确信你真的想花时间下载中文字符数据么？
缓存框架

Heider回顾了Flex 3 support for runtime-shared-libraries （RSL）这篇文章：从Flex 3开始，你可以将Adobe签名的框架——RSLs缓存到 Player的中。这有两个好处。首先，缓存在 Player 中的签名的框架RSLs可由所有配置好的Flex应用共享。换句话说，如果某人的应用已经下载了500k的签名的框架RSL，并且该RSL仍旧 在 Player 中，那么你的应用就可以使用缓存下来的RSL。其次，即使某人清空了其浏览器缓存，对 Player 也没有任何影响。

考虑模块化
Heider谈到了将Flex应用划分成模块的好处：减少字体加载时间的另一种方式就是将你的Flex应用划分成模块。使用模块的一个好处在于当加载和卸载模块时你能完全操控它。
之所以要划分成模块的最后一个原因是他们更快，而且我能即时加载它们。换句话说，在启动时唯一需要加载的模块就是 Step1.swf模块。因此，在使用模块的情况下，最终用户节省了启动时间，但是当他从一个模块切换到另一个模块时却需要花更多时间，因为每个模块都需 要以JIT形式加载。在我的应用中，只有当用户首次在steps 1-5之间切换时需要花更多时间。

推迟实例化
Heider围绕着Flex组件的“creationPolicy”属性及何时实例化应用的不同部分给出了很多建议。如果你想减少从数据下载到用户真正可以使用的总时间，当务之急就是推迟实例化。这项技术背后的理念就是直到应用真正使用的时候才在内存中创建对象。尽管推迟实例化技术会在应用的整个使用过程中导致少许——通常不那么明显——的延迟，但与长时间的启动延迟相比，它还是可接受的。推迟实例化的另一个好处在于内存使用的优化。 Heider还谈到了一个“实验性”的条款——“使用流”，这是他在讨论Dirk Eismann的帖子（Building monolithic Flex SWFs that still startup quickly.”）时谈及的。Eismann提出一项技术以利用 Player中的多个frames以在部分应用中达到流的目的。查看所有的帖子以更多地了解该技术及关于加快Flex启动速度的建议。中国最大的RIA分享社区-与中国闪客一起成长和发展！)

原文出处：http://www.infoq.com/cn/news/2008/05/flex-startup-time

Posted in: life Comments(0) September 2008


google背后的分布式架构

Posted by dengwei

　　Google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的IT策略……

　　加利福尼亚州山景城(Mountain View)Google公司(Google，下称Google)总部有一个43号大楼，该建筑的中央大屏幕上显示着一个与Google地球(Google Earth)相仿的世界地图，一个转动的地球上不停地闪动着五颜六色的光点，恍如罗马宫廷的千万烛灯，每一次闪动标志着地球的这个角落一名Google用 户发起了一次新的搜索。

　　这同时意味着Google又一次满足了人们对未知信息的好奇与渴望。

　　Google是与众不同的。它的独特不仅仅表现于革新的思维和充满创意的应用 (比如那个大堂里的地球模型)，更在于其有别常规的IT策略。从人们的常理来看，简单的硬件商品和免费软件是无法构建出一个帝国的，但是Google做到 了。在性能调整后，Google把它们变成一个无可比拟的分布式计算平台，该平台能够支持大规模的搜索和不断涌现的新兴应用。我们原本认为这些应用都是个 人消费级别的，但是Google改变了这一切。现在商业世界也在使用它们，这就令这家搜索公司显得那么与众不同。

　　GoogleWeb 服务背后的IT架构对无数使用搜索引擎的用户来说也许并不是非常重要，但它是Google几百位致力于把全球信息组织起来，实现“随处可达，随时可用”目 标的工程师们的最核心工作。这就需要一个在覆盖范围和野心上都与Google的商业愿景完全相符的IT蓝图作为支撑。

　　Google 的经理们一直对公司的IT策略话题保持沉默，他们厌恶谈及特定的厂商或者产品，当被问到他们的服务器和数据中心时，他们总是闭口不谈。但与几位 Google的IT领导一起呆了一天后，我们最终得以揭示该公司的IT是如何运作的，那可不仅仅是一个运行在无数服务器集群上的、表面看来非常简单的搜索 引擎。在其简单的外表下，蕴涵着许多内部研发软件、定制硬件、人工智能，以及对性能的执着追求和打破常规的人力管理模式。

　　IT理念方面，Google对同行有一条建议：尽量避免那些人人都在使用的系统和软件，以自己的方式做事会更有独特的竞争优势。

　　“企业文化决定了你的做事方式。”道格拉斯”美林(Douglas Merrill)，这位Google工程副总裁和事实上的首席信息官(CIO) 指出，“到了我们这样的发展阶段，企业观念和文化非常与众不同，这也反过来鞭策我们必须要采用与众不同的方式来运行那些他人看来很常规的系统。”
　　Google 最大的IT优势在于它能建造出既富于性价比(并非廉价)又能承受极高负载的高性能系统。因此IT顾问史蒂芬”阿诺德(Stephen Arnold)指出，Google与竞争对手，如亚马逊网站(Amazon)、电子港湾公司(eBay)、微软公司(Microsoft，下称微软)和雅 虎公司 (Yahoo，下称雅虎)等公司相比，具有更大的成本优势。Google程序员的效率比其他公司同行们高出50%～100%，原因是Google已 经开发出了一整套专用于支持大规模并行系统编程的定制软件库。据他估算，其他竞争公司可能要花上四倍的时间才能获得同等的效果。

　　打造服务器

　　Google 究竟是怎样做到这点的呢?其中一个手段，美林认为，“是因为我们自己动手打造硬件。”Google并不制造计算机系统，但它根据自己的参数定制硬件，然后 像MTV的节目“靓车打造”(Pimp My Ride)那样自己安装和调整硬件系统。开源程序经理克里斯”迪博纳(Chris DiBona)评论道：“我们很善于购买商业服务器，并且改造他们为我们所用，最后把性能压榨和发挥到极致，以致有时候他们热得像要融化了似的。”

　　这种亲手打造的方式，来源于Google从车库诞生时与生俱来的节俭风格，更与Google那超大型的系统规模息息相关，良好的习惯一直延续至 今。据说 Google在65个数据中心拥有20万～45万台服务器—这个数目会有偏差(取决于你如何定义服务器和由谁来做这项统计)。但是，不变的是持续上升的趋势。

　　Google不会去讨论这些资产，因为它认为保密也是一种竞争优势。事实上，Google之所以喜欢开源软件也是因为它的私密性。“如果我们购 买了软件许可或代码许可，人们只要对号入座，就可以猜出Google的IT基础架构。”迪博纳分析说， “使用开源软件，就使我们多了一条把握自己命运的途径。”

　　Google喜欢规模化的服务器运行方式。当有成百上千台机器时，定制服务器的优势也会成倍增加，效果也会更趋明显。Google正在俄勒冈州 哥伦比亚河边的达勒斯市建造一个占地30亩的数据中心，在那儿它可以获得运算和降温需要的低价水力电力能源(参见边栏《Google数据中心自有一套》)。

　　Google以“单元”(Cell)的形式组织这些运行 操作系统的服务器，迪博纳把这种形式比喻成互联网服务的“磁盘驱动器”(但别和一直谣传的Google存储服务Gdrive混淆了，“并没有 Gdrive这回事。”一位Google女发言人明确表示。)，公司的软件程序都驻扎在这些并不昂贵的电脑机箱里，由程序员决定它们的冗余工作量。这种由 很多单元组成的文件系统代替了商业存储设备;迪博纳表示Google这些单元设备更易于建造和维护，他还暗示他们能处理更大规模的数据。

　　Google 不会漏过对任何技术细节的关注。多年来，公司的工程师就在研究微处理器的内部工作机制，随着Google规模的持续壮大，必然会用到特别定制和调节过的芯 片。知名工程师路易斯”巴罗索(Luiz Barroso)去年在一篇发表在工业杂志上的论文中证实，近年来Google的主要负荷都由单核设计的系统承担着。但许多服务器端的应用，如 Google搜索索引服务，所需的并行计算在单核芯片的指令级别上执行得并不好。

　　曾在数据设备公司(Digital Equipment)和康柏公司(Compaq)当过芯片设计师的巴罗索认为，随着AMD公司、英特尔公司(Intel)、太阳计算机系统公司(Sun)开始制造多核芯片，必将会出现越来越多芯片级别的并行计算。

　　Google 也曾考虑过自己制造计算机芯片，但从业界潮流来看，这个冒险的举动似乎不是很必要。“微处理器的设计非常复杂而且成本昂贵，”运营高级副总裁乌尔斯”霍尔 茨勒(Urs Holzle)表示。Google宁愿与芯片制造商合作，让他们去理解自己的应用并设计适合的芯片。这是一种客户建议式的设计，其关注点在于总体吞吐量、 效能，以及耗电比，而不是看单线程的峰值性能。霍尔茨勒表示，“这也是最近多核CPU的设计潮流与未来方向。”
裁缝般地定制软件

　　为了能尽量压榨硬件性能，Google开发了相当数量的定制软件。创新产品主要包括用于简化处理和创建大规模数据集的编程模型 MapReduce;用于存储和管理大规模数据的系统BigTable;分析分布式运算环境中大规模数据集的解释编程语言Sawzall;用于数据密集型 应用的分布式文件系统的 “Google文件系统”(Google File System);还有为处理分布式系统队列分组和任务调度的“Google工作队列”(Google Workqueue)。

　　正是从Sawzall这些工具里体现出Google对计算效率的执著关注。并不是每家公司都能从底层去解决效率问题，但是对Google来说， 为常规关系型数据库无法容纳的大规模数据集专门设计一种编程语言是完全合理的。即使其他编程工具可以解决问题，Google的工程师们仍然会为了追求效率 而另外开发一套定制方案。Google工程师认为，Sawzall能与++中的MapReduce相媲美，而且它更容易编写一些。

　　Google 对效率的关注使它不可能对标准内核感到满意;Google会根据自己的需要运行修改过的内核版本。通过调整的底层性能，Google 工程师们在提高了整体系统可靠性的基础上，还一并解决了数据损坏和数据瓶颈等一系列棘手问题。对内核的修改也使Google的计算机集群系统因为通信效率 的提高而运行得更快。

　　当然，Google偶尔也会出现系统故障，情况一旦发生，无数的用户就会受到影响了。三年前一次持续30分钟的系统故障使20%的搜索流量受到影响。

　　Google 开发了自己的网站服务器却没有使用开源的Apache服务器，尽管它在网站服务器的市场占有率超过60%。迪博纳认为，Google的网站服务器可以运行 在更多数量的主机上，对Google站点上内容庞大又彼此互相依赖的应用程序来说，这种服务器的负载均衡能力远比Apache的能力更高。同时，在用标准 公共网关接口(CGI)访问数据库动态网页方面，Google服务器的编程难度要比 Apache更高，但是最终运行速度却更快。“如果我们能够压榨出10%～20%的性能，我们就可以节省出更多系统资源、电量和人力了。”迪博纳在总结中指出。

　　Google还设计了自己的客户关系管理(CRM)系统用于支持自己基于竞价和点击的互联网广告收费业务。但对是否需要设计自己的工具，Google的态度也不是一成不变的。比如在财会软件上，它就使用了甲骨文公司(Oracle)的Financials软件。

　　美林拿着一只叉子举例说明现成的产品也可以带来价值。但在有些场合现成的软件产品就不一定适用了。“我们的文化在各个层面对我们的运作都有深远影响，”他表示，“所以我们不想让购买所得的工具改变我们的工作方式和文化层面。”
Google’s BigTable 原理 （翻译）

题记：google 的成功除了一个个出色的创意外，还因为有 Jeff Dean 这样的软件架构天才。
—— 编者

官方的 Google Reader 中有对BigTable 的解释。这是Google 内部开发的一个用来处理大数据量的系统。这种系统适合处理半结构化的数据比如 RSS 数据源。 以下发言 是 Andrew Hitchcock 在 2005 年10月18号 基于： Google 的工程师 Jeff Dean 在华盛顿大学的一次谈话 (Creative Commons License).

首先，BigTable 从 2004 年初就开始研发了，到现在为止已经用了将近8个月。（2005年2月）目前大概有100个左右的服务使用BigTable，比如： Print,Search History,Maps和 Orkut。根据Google的一贯做法，内部开发的BigTable是为跑在廉价的PC机上设计的。BigTable 让Google在提供新服务时的运行成本降低，最大限度地利用了计算能力。

BigTable 是建立在 GFS ，Scheduler ，Lock Service 和 MapReduce 之上的。

每个Table都是一个多维的稀疏图 sparse map。Table 由行和列组成，并且每个存储单元 cell 都有一个时间戳。在不同的时间对同一个存储单元cell有多份拷贝，这样就可以记录数据的变动情况。在他的例子中，行是URLs ，列可以定义一个名字，比如：contents。Contents 字段就可以存储文件的数据。或者列名是：”language”，可以存储一个“EN”的语言代码字符串。

为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每 个Tablets大概有 100-200 MB，每个机器存储100个左右的 Tablets。底层的架构是：GFS。由于GFS是一种分布式的文件系统，采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应 的表移动到其他空闲机器上，然后快速重建。

Tablets在系统中的存储方式是不可修改的 immutable 的SSTables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些Tablets。由于Jeff在论述这点的时候说的很快，所以我没有时间把听到的都记录下来，因此下面是一个大概的说明：

压缩分为：主要和次要的两部分。次要的压缩仅仅包括几个Tablets，而主要的压缩时关于整个系统的压缩。主压缩有回收硬盘空间的功能。Tablets的位置实际上是存储在几个特殊的BigTable的存储单元cell中。看起来这是一个三层的系统。
客户端有一个指向METAO的Tablets的指针。如果METAO的Tablets被频繁使用，那个这台机器就会放弃其他的tablets专门支持 METAO这个Tablets。METAO tablets 保持着所有的META1的tablets的记录。这些tablets中包含着查找tablets的实际位置。（老实说翻译到这里，我也不太明白。）在这个系统中不存在大的瓶颈，因为被频繁调用的数据已经被提前获得并进行了缓存。

现在我们返回到对列的说明：列是类似下面的形式： family:optional_qualifier。在他的例子中，行：www.search-analysis.com 也许有列：”contents:其中包含页面的代码。 “ anchor:cnn.com/news” 中包含着 相对应的url，”anchor:www.search-analysis.com/” 包含着链接的文字部分。列中包含着类型信息。
(翻译到这里我要插一句，以前我看过一个关于万能数据库的文章，当时很激动，就联系了作者，现在回想起来，或许google的 bigtable 才是更好的方案，切不说分布式的特性，就是这种建华的表结构就很有用处。)

注意这里说的是列信息，而不是列类型。列的信息是如下信息，一般是：属性/规则。 比如：保存n份数据的拷贝或者保存数据n天长等等。当 tablets 重新建立的时候，就运用上面的规则，剔出不符合条件的记录。由于设计上的原因，列本身的创建是很容易的，但是跟列相关的功能确实非常复杂的，比如上文提到 的 类型和规则信息等。为了优化读取速度，列的功能被分割然后以组的方式存储在所建索引的机器上。这些被分割后的组作用于 列 ,然后被分割成不同的 SSTables。这种方式可以提高系统的性能，因为小的，频繁读取的列可以被单独存储，和那些大的不经常访问的列隔离开来。

在一台机器上的所有的 tablets 共享一个log，在一个包含1亿的tablets的集群中，这将会导致非常多的文件被打开和写操作。新的log块经常被创建，一般是64M大小，这个GFS的块大小相等。当一个机器down掉后，控制机器就会重新发布他的log块到其他机器上继续进行处理。这台机器重建tablets然后询问控制机器处理结构的存储位置，然后直接对重建后的数据进行处理。这个系统中有很多冗余数据，因此在系统中大量使用了压缩技术。

Dean 对压缩的部分说的很快，我没有完全记下来，所以我还是说个大概吧：压缩前先寻找相似的 \行，列，和时间数据。

他们使用不同版本的： BMDiff 和 Zippy 技术。

BMDiff 提供给他们非常快的写速度： 100MB/s – 1000MB/s 。Zippy 是和 LZW 类似的。Zippy 并不像 LZW 或者 gzip 那样压缩比高，但是他处理速度非常快。

Dean 还给了一个关于压缩 蜘蛛数据的例子。这个例子的蜘蛛 包含 2.1B 的页面，行按照以下的方式命名：“com.cnn.www/index.:http”.在未压缩前的 page 页面大小是：45.1 TB ，压缩后的大小是：4.2 TB ， 只是原来的 9.2%。Links 数据压缩到原来的 13.9% , 链接文本数据压缩到原来的 12.7%。
Read the rest of this entry »

Posted in: life Comments(0) September 2008


[转] C语言的setjmp: 异常处理与构建协作式多任务系统

Posted by gavinkwoe

转至 http://www.upsdn.net/html/2004-11/47.html

在标准库中有一对非常有趣的函数()函数与()函数,用来实现代替实现一些非常重要的功能，如异常处理。语言中，标准库函数和形成了结构化异常工具的基础。简单的说即实例化异常处理程序，而产生异常。

先介绍
int (jmp_buf envbuf)
宏函数()在缓冲区envbuf中保存系统堆栈里的内容，供()以后使用,()必须使用头文件.h。
调用()宏时，返回值为0，然而()把一个变原传递给(),该值（恒不为0）就是调用()后出现的()的值。
函数用于保存程序的运行时的堆栈环境，接下来的其它地方，你可以通过调用函数来恢复先前被保存的程序堆栈环境。当和组合一起使用时，它们能提供一种在程序中实现“非本地局部跳转”（”non-local ”）的机制。并且这种机制常常被用于来实现，把程序的控制流传递到错误处理模块之中；或者程序中不采用正常的返回（return）语句，或函数的正常调用等方法，而使程序能被恢复到先前的一个调用例程（也即函数）中。
对函数的调用时，会保存程序当前的堆栈环境到env参数中；接下来调用时，会根据这个曾经保存的变量来恢复先前的环境， 并且当前的程序控制流，会因此而返回到先前调用时的程序执行点。此时，在接下来的控制流的例程中，所能访问的所有的变量（除寄存器类型的变量 以外），包含了函数调用时，所拥有的变量。
void (jmp_buf envbuf,int status);
     函数()使程序在最近一次调用()出重新执行。()和()提供了一种在函数间调转的手段，必须使用头部文件.h。
     函数()通过把堆栈复位成envbuf中描述的状态进行操作，envbuf的设置是由预先调用()生成的。这样使程序的执行在 ()调用后的下一个语句从新开始，使计算机认为从未离开调用()的函数。从效果上看，()函数似乎“绕”过了时间 和空间（内存）回到程序的原点，不必执行正常的函数返回过程。
     缓冲区envbuf具有<.h>中定义的buf_jmp类型，它必须调用()前通过调用()来设置好。
    值status变成()的返回值，由此确定长调转的来处。不允许的唯一值是0，0是程序直接调用函数()时由该函数返回的，不是间接通过执行函数()返回的。
     ()函数最常用于在一个错误发生时，从一组深层嵌套的实用程序中返回。
函数用于恢复先前程序中调用的函数时所保存的堆栈环境。和组合一起使用时，它们能提供一种在程序中实现“非本地局部跳转”（”non-local ”）的机制。并且这种机制常常被用于来实现，把程序的控制流传递到错误处理模块，或者不采用正常的返回（return）语句，或函数的正常调用等方法，使程序能被恢复到先前的一个调用例程（也即函数）中。

　 　对函数的调用时，会保存程序当前的堆栈环境到env参数中；接下来调用时，会根据这个曾经保存的变量来恢复先前的环境，并且 因此当前的程序控制流，会返回到先前调用时的执行点。此时，value参数值会被函数所返回，程序继续得以执行。并且，在接下来 的控制流的例程中，它所能够访问到的所有的变量（除寄存器类型的变量以外），包含了函数调用时，所拥有的变量；而寄存器类型的变量将不可预 料。函数返回的值必须是非零值，如果传送的value参数值为0，那么实际上被返回的值是1。

　　在调用的函数返回之前，调用，否则结果不可预料。

在使用时，请遵守以下规则或限制：
　　· 不要假象寄存器类型的变量将总会保持不变。在调用之后，通过所返回的控制流中，例程中寄存器类型的变量将不会被恢复。
　　· 不要使用函数，来实现把控制流，从一个中断处理例程中传出，除非被捕获的异常是一个浮点数异常。在后一种情况下，如果程序通过调用 _fpreset函数，来首先初始化浮点数包后，它是可以通过来实现从中断处理例程中返回。
如何实现异常处理
首先设置一个跳转点（() 函数可以实现这一功能），然后在其后的代码中任意地方调用 () 跳转回这个跳转点上，以此来实现当发生异常时，转到处理异常的程序上，在其后的介绍中将介绍如何实现。 () 为跳转返回保存现场并为异常提供处理程序，() 则进行跳转（抛出异常），() 与 () 可以在函数间进行跳转，这就像一个全局的 语句，可以跨函数跳转。

jmp_buf 异常结构

        使用 () 及 () 函数前，需要先认识一下 jmp_buf 异常结构。jmp_buf 将使用在 () 函数中，用于保存当前程序现场（保存当前需要用到的寄存器的值），jmp_buf 结构在 .h 文件内声明：

        typedef struct
        {
                unsigned j_sp;  // 堆栈指针寄存器
                unsigned j_ss;  // 堆栈段
                unsigned j_flag;  // 标志寄存器
                unsigned j_cs;  // 代码段
                unsigned j_ip;  // 指令指针寄存器
                unsigned j_bp; // 基址指针
                unsigned j_di;  // 目的指针
                unsigned j_es; // 附加段
                unsigned j_si;  // 源变址
                unsigned j_ds; // 数据段
        } jmp_buf;

        jmp_buf 结构存放了程序当前寄存器的值，以确保使用 () 后可以跳回到该执行点上继续执行。

() 与 () 函数都使用了 jmp_buf 结构作为形参，它们的调用关系是这样的：
        首先调用 () 函数来初始化 jmp_buf 结构变量 jmpb，将当前CPU中的大部分影响到程序执行的积存器存入 jmpb，为 () 函数提供跳转，() 函数是一个有趣的函数，它能返回两次，它应该是所有库函数中唯一一个能返回两次的函数，第一次是初始化时，返回零，第二次遇到 () 函数调用后，() 函数使 () 函数发生第二次返回，返回值由 () 的第二个参数给出（整型，这时不应该再返回零）。
        在使用 () 初始化 jmpb 后，可以其后的程序中任意地方使用 () 函数跳转会 () 函数的位置，() 的第一个参数便是 () 初始化的 jmpb，若想跳转回刚才设置的 () 处，则 () 函数的第一个参数是 () 所初始化的 jmpb 这个异常，这也说明一件事，即 jmpb 这个异常，一般需要定义为全局变量，否则，若是局部变量，当跨函数调用时就几乎无法使用（除非每次遇到函数调用都将 jmpb 以参数传递，然而明显地，是不值得这样做的）；() 函数的第二个参数是传给 () 的第二次返回值，这在介绍 () 函数时已经介绍过。
        下面是 () 函数与 () 函数的一个示意图：

通过示意图可以看出 () 函数与 () 函数的关系，如何跳转。

呵呵！现在是否对程序的执行流程一目了然，其中最关键的就是setjjmp和函数的调用处理。我们分别来分析之。
　　当程序运行到第②步时，调用函数，这个函数会保存程序当前运行的一些状态信息，主要是一些系统寄存器的值，如ss，cs，eip， eax，ebx，ecx，edx，eflags等寄存器，其中尤其重要的是eip的值，因为它相当于保存了一个程序运行的执行点。这些信息被保存到 mark变量中，这是一个标准库中所定义的特殊结构体类型的变量。
　　调用函数保存程序状态之后，该函数返回0值，于是接下来程序执行到第③步和第④步中。在第④步中语句执行时，如果变量n2为0值，于是便 引发了一个浮点数计算异常，，导致控制流转入fphandler函数中，也即进入到第⑤步。
　　然后运行到第⑥步，调用函数，这个函数内部会从先前的所保存的程序状态，也即mark变量中，来恢复到以前的系统寄存器的 值。于是便进入到了第⑦步，注意，这非常有点意思，实际上，通过函数的调用后，程序控制流（尤其是eip的值）再次戏剧性地进入到了 函数的处理内部中，但是这一次返回的值是函数调用时，所传入的第2个参数，也即-1，因此程序接下来进入到了第⑧ 步的执行之中。
因为 jmp_buf 全局只能存放一个 jmpb 结构，使得只有最后一组宏可以响应异常；    这是无法嵌套异常的原因，要实现多重嵌套可以建立一个全局堆栈来维护一组 jmpb 结构
实现机理
()保存其调用返回点的ebx, esi, edi, ebp, esp, eip,对于sigsetjmp(), 还保存当前的信号屏蔽字, 恢复这些寄存器及信号屏蔽字,同时传递一个返回值。
ongjmp只是使CPU的状态和时的状态一致，相同的CPU初始状态执行相同的代码并不意味着产生相同的结果,, 并不关心内存变量的变化，而只关心CPU的状态,
内存变量的确定性应该根据上下文来灵活处理.
如果将函数之间的调用关系看成一种树型结构, 将可执行文件的入口函数看成它的最内层节点(根节点), 那么提供了标记节点的方法, 提供了从外层节点直接返回到更内层节点的方法,
在同一层节点之间或者从内层节点到外层节点的是没有意义的, 因为目标节点在此时根本不存在.
摘要：讨论一个利用标准语言库函烽实现查询式协作多任务系统，给出完整的内核和样例程序并对源代码进行说明。该系统具有简单易用的特点，只需要编写存取堆栈指针的宏就可方便地移植到新的平台上。文章详述了系统的优缺点，讨论一些性能扩展的方法。该内核适用
于中小规模的嵌入式软件。

关键词：协作式多任务 语言

引言

本文介绍的是利用标准语言库函数实现的具备此特点的协作式多任务系统。从本 质上讲，实时多任务操作系统应该具备按照优先级抢占调度的内核。然而，在实际应用中，抢中式的多任务某种程序上带来了用户程序设计时数据保护的困难，并 且，具备抢占功能的多任务内核设计时困难也比较多，这会增加操作系统自身的代码，也使它在小资源单片机系统中应用较少；而协作多任务系统的调度只在用户指 定的时机发生，这会大大简化内核和用户系统的设计，尤其本文实现的系统通过条件查询来放弃CPU，既符合传统单片机程序设计的思维，又带来了多任务、模块 化、可重入的编程便利。

是标准语言库函数的组成部分，它可以实现程序执行中的远程转操作。具体来 说，它可以在一个函数中使用来初始化一个全局标号，然后只要该函数未曾返回，那么在其它任何地方都可以通过调用来跳转到 的下一条语句执行。实际上，函数将发生调用处的局部环境保存在一个jmp_buf的结构当中，只要主调函数中对应的内存未曾释放 （函数返回时局部内存就失效了），那么在调用的时候就可以根据已保存的jmp_buf参数恢复到的地方执行。我们的系统中就是 分析了标准库函数的特点，以简单的方式实现了协作式多任务。

1 演示程序

为了便于理解，首先给出多任务演示程序的源代码。这个程序演示了协作式多任务切换、任务的 动态生成、多任务共用代码等功能，一共使用了init_coos初始化根任务（也就是语言main函数）、creat_task创建新任务和 WAITFOR查询条件这3个基本的系统调用。由于面向嵌入式系统，因而程序不会中止并且运行中也没有进行任何输出，需要借助适合的调试工具来理解多任务 系统的运行。

example.文件清单：

#include<stdlib.h>

#include“co-os.h”

void tskfunc1(int argc,void *argv);

void tskfunc2(int argc,void *argv);

void subfunc(void);

volatile int cnt,test;

int main(void){

int i;

init_coos(400);

creat_tsk(tskfunc1,12,NULL,400);

creat_tsk(tskfunc2,0,NULL,400);

i=0；

while(1){

WAITFOR(cnt= =8);

while(i++<cnt)test=i;

cnt++;

}

}

void tskfunc1(int argc,void *argv){

int i;

static int creat=0;

if(!creat){

creat_tsk(tskfunc1,9,NULL,400);

creat=1;

}

i=0；

while(1){

WAITFOR(cnt>argc);

test=0×55;

/*使用函数调用在子程序中测试WAITFOR*/

subfunc()；

while(i++<cnt)test=i^0xAA;

}

}

void tskfunc2(int argc,void *argv){

while(1){

WAITFOR(++cnt>15);

cnt=0;

}

}

void subfunc(void){

int i;

WAITFOR(cnt<5);

for(i=0;i<++)test=0×10*i；

}

2 内核构成

内核包括一个供外部用户程序包含的头文件（co-os.h）和具体实现的源文件（co-os.），它们提供了演示程序中用到的3个系统调用。

内核的实现代码假定了CPU堆栈是向下增长的，并且通过宏来直接操作堆栈指针。以下代码在 Microsoft VC6 for x86、Borland ++ Builder 5.5、SDS CrossCode7.0 for 68K和GCC3.2 for AVR四种平台中测试过，只需在co-os.h头文件中定义相应的平台类型即可顺利编译。

（1）co-os.h文件清单

#include<.h>

/*选择X86_VC6，X86_BC5，AVR_GCC或M68H_SDS.*/

#define X86_VC6

#define MAX_TSK 10

typedef struct {

void (*entry)(int argc,void *argv);

jmp_buf env;

int argc;

void *argv;

}TVB;

extern TCB tcb[MAX_TSK];

extern int task_num,tskid;

void init_coos(int mainstk);

int creat_tsk(void(*entry)(int argc,void *argv),int argc,void *argv,int stksize);

#define WAITFOR(condition)do{

(tcb[tskid].env);

if(!(condition)){

tskid++;

if(tskid>=task_num)tskid=0;

longijmp(tcb[tskid].env,1);

}

}while(0)

(2)co-os.文件清单

#include “co-os.h”

#if defined(X86_VC6)||defined(X86_BC5)

#define SAVE_SP(p) _asm mov p,esp

#define RESTORE_SP(p) _asm mov esp,p

#elif defined(AVR_GCC)

#include<io.h>

#define SAVE_SP(p) p=(int*)SP

#define RESTORE_SP(p) SP=(int)p

#elif defined(M68K_SDS)

#define SAVE_SP(p) asm(”MOVE.L A7,{”#p”}”)

#define RESTORE_SP(p) asm(”MOVE.L {”#p”},A7″)

#endif

TCB tcb[MAX_TSK];

Int task_num=1;

Int tskid;

Static int stktop,oldsp;

Void init_coos(int mainstk){

SAVE_SP(stktop);

stktop=stktop+sizeof(void(*)(void))/sizeof(int)

-(mainstk+sizeof(int)-1)/sizeof(int);

}

int creat_tsk(void(*entry)(int argc,void *argv),

int argc,void *argv,int stksize){

if(task_num>=MAX_TSK)terurn-1;

SAVE_SP(oldsp);

RESTORE_SP(stktop);

If(!(tcb[task_num].env)){

RESTORE_SP(oldsp);

tcb[task_num].entry=entry;

tcb[task_num].argc=argc;

tcb[task_num].argv=argv;

task_num++;

stktop-=(stksize+sizeof(int)-1)/sizeof(int);

}

else tcb[tskid].entry(tcb[tskid].argc,tcb[tskid].argv);

return 0;

}

3 代码说明

任务代码通过执行设置本任务下次查询时的返回点，然后在等待条件放弃掉CPU 跳转到下一任务的返回点处执行。如此周而复始，让各任务都获得轮转运行的机会，也要求各任务都需要主动通过等待条件的方式放弃掉CPU。系统中除了中断服 务程序之外，所有任务都是平等的，都应该遵循同样的规则和其它任务一起协作运行。基本系统中没有设计杀死任务的调用，这要求各任务都应当设计成某种形式的 无限循环。

任务中等待的条件可以是任务复杂的表达式或都函数调用，也可以是中断服务程序设置的全局变 量（注意加volatile定义）。一般在任务执行时会让下次等待的条件不再满足，避免某个任务一直霸占CPU将系统饿死。在嵌入式软件中还经常会遇到任 务定时启动和超时等待在I/O操作上，在我们的系统中可以维护一个时间计数器，只需在适当的地方记录时刻，然后在任务查询条件中判断当前计数器和记录时刻 之间的差值就可以了。

内核实现的代码则相当简法。由于主要的保护和恢复任务现场的工作都由语言标准库 实现了，我们就只需要操纵一下堆栈指针防止不同的任务使用了重叠的局部环境，这个工作在初始化和创建任务的时候通过预定义的两个宏来实现。在 init_coos函数中，记录了主任务（main函数）保留mainstk字节堆栈后的新栈顶位置（stktop），然后在每次creat_task时 都根据要求为每个任务保留stksize字节的堆栈并重新计算下一个stktop。在creat_task函数中利用了函数的返回值（直接返 回时为0，跳转返回时非0），使得一方面creat_task能正常回到调用者，又让下次轮转到新任务时能够找到创建时的入口。

co-os.h中定义的WAITFOR使用了一个do{…while(0)实现多语句宏的 语言小技巧，这样能保证在任何情况下WAITFOR都可以如单条语句一样在源程序中使用，需要担心多了或者少了大括弧破坏if/else匹配之类的问 题，并且，所有的编译器都会优化掉这个假循环。

为了尽量使程序简单并说明问题，以上代码中没有考虑中断相关的数据保护问题。实际运行的系 统中，如果首先写堆栈指针不能一步完成（如AVR这样的8位机），那么，在写操作正在进行的时候绝对不能允许中断；另外，在任务中查询的条件如果和中断有 关，那么也必须考虑数据的完整性。

4 性能分析

所有的协作式多任务系统中任务切换时间都和用户代码（是否长期占用CPU）、就绪时刻有 关，比标准系统略差的是，我们的简单系统中不支持任务优先级，并且完成一轮查询调度的时间还和任务数目有关。这也是为了达到简单和可移植性目标而不得已作 出的牺牲。在各任务间切换查询条件通过语言标准库函数实现，一般来讲函数要从内存中恢复大部分CPU寄存器，执行它也需要 若干条指令的时间。

为了面向嵌入式系统应用，任务控制块（TCB）采用静态数组来实现，这样要求预先确定系统 的最大任务数（co-os.h中的MAX_TSK）。如果需要，也可以通过环波链表来动态管理任务控制块（TCB），这时可以简单实现任务的动态创建和删 除，并且通过指针来访问TCB也要比通过下标（tskid）略快一点。

在某些情况下，如果在中断返回后需要执行某关键任务，可以考虑通过设置“高级中断”的方法 来实现。具体地讲，就是在中断返回前改变返回地址到某函数入口（“高级中断服务程序”），同时保留原返回地址到堆栈中，这样在“高级中断服务程序”完成后 执行return就又回到了正常的多任务查询流程。使用“高级中断”时要注意现场保护的衔接，并且这种技巧显然和CPU和体系结构有关。

5 结论

是标准语言中用于远程跳转的库函数，利用它可方便实现一个简单易移植的协作式多任务系统。该系统功能完备、编程简单、易于学习，适合一些中小规模的嵌入式软件使用；并且，以此为基础，还可以用一些与平台相关的编程技巧提高其实时性和灵活性。

部分资料来源于希赛,单片机与嵌入式系统应用

Posted in: c/c++/c# Comments(0) December 2007


[转] MTK平台芯片概说

Posted by gavinkwoe

转至 http://blog.sina.com.cn/mobliephone

目前联发科技已开发出MT6205、MT6217、MT6218、MT6219、MT6226、MT6227、MT6228等系列平台,其中MT6205、MT6217、MT6218、MT6219、MT6226、MT6227、MT6228、MT6229、MT6225、MT6223、MT6230均为基带芯片，所有芯片均采用ARM7的核。
MT6305为电源管理芯片，有MT6305、MT6305N、MT6305BN；

MT6129、MT6139是射频芯片。MT6129为早期的射频RF芯片，一般与MT6205的CPU一起使用。现在用的多的是MT6129C、MT6129N、MT6129D，其中MT6129C、MT6129N一般用在MT6217、MT6218、MT6219的CPU的机器上，MT6129D一般用在MT6226、MT6227的CPU的机器上。RF3146（7×7mm）、RF3146D（双频）、RF3166（6×6mm）为RFMD的PA。

MT6205为最早的方案，只有GSM的基本功能，不支持GPRS、WAP、MP3等功能。(2003年MP)；
MT6218为在MT6205基础上增加GPRS、WAP、MP3功能。MT6217为MT6218的cost down方案，与MT6128 PIN TO PIN，只是软件不同而已，另外MT6217支持16bit数据。（2004年MP）
MT6219为MT6218上增加内置AIT的1.3M camera处理IC，增加MP4功能。8bit数据。（2005年MP）
MT6226为MT6219 cost 升级产品，内置0.3M 摄相处理IC，支持GPRS、WAP、MP3、MP4等，内部配置比MT6219优化及改善，比如配蓝牙是可用很便宜的芯片CSR的BC03模块USD3即可支持数据传输（如听立体声MP3等）功能。
MT6226M为MT6226高配置设计，内置的是1.3M摄像处理IC。（2006年MP）
MT6227与MT6226功能基本一样，PIN TO PIN，只是内置的是2.0M 摄像处理IC。（2006年MP）
MT6228比MT6227增加TV OUT功能，内置3.0M 摄像处理IC，支持支持GPRS、WAP、MP3、MP4。（2006年MP）
从MT6226后软件均可支持网络摄像头功能，也就是说你的机子可以用于QQ视频。

MT6229平台支持EDGE功能，其他功能和6228基本一致。

MT6225是6217的代替产品，可以接cam但是没有isp，也就是没有特效，变焦，但是其主频很高和6228/6229一样达到了104mhz,可以接wifi,并且给设计公司提出了更高的要求——如何利用104m的资源去实现mp4的编解码，如何用104m的资源跑更多的应用，这些都是设计公司做的,对设计公司的要求也非常得高。

MT6223是6205的替代，支持语音，短信，MP3,不支持T_F卡，USB盘，没有集成ISP，PMIC内签。

目前市面上出的双卡双待手机,一般是采取的方案分为以下几种:MT6226+6205,MT6225+6205和MT6225+6223

Posted in: doc Comments(0) November 2007


做网站的一些定律

Posted by gavinkwoe

1.250定律

拉德认为：每一位顾客身后，大体有250名亲朋好友。如果您赢得了一位顾客的好感，就意味着赢得了250个人的好感；反之，如果你得罪了一名顾客，也就意味着得罪了250 名顾客。   在你的网站访客中，一个访客可能可以带来一群访客，任何网站都有起步和发展的过程，这个过程中此定律尤其重要。

2.达维多定律

达维多认为，一个企业要想在市场上总是占据主导地位，那么就要做到第一个开发出新产品，又第一个淘汰自己的老产品。   国内网站跟风太严重，比如前段时间的格子网，乞讨网，博客网，一个成功了，大家一拥而上。但实际效果是，第一个出名的往往最成功，所以在网站的定位上，要动自己的脑筋，不是去捡人家剩下的客户。同理，买人家出售的数据来建站效果是很糟糕的。

3.木桶定律

水桶定律是指，一只水桶能装多少水，完全取决于它最短的那块木板。这就是说任何一个组织都可能面临的一个共同问题，即构成组织的各个部分往往决定了整个组织的水平。   注意审视自己的网站，是速度最糟糕？美工最糟糕？宣传最糟糕？你首先要做的，不是改进你最强的，而应该是你最薄弱的。

4.马太效应

《新约》中有这样一个故事，一个国王远行前，交给三个仆人每人一锭银子，吩咐他们：“你们去做生意，等我回来时，再来见我。”国王回来时，第一个仆人说： “主人，你交给我们的一锭银子，我已赚了10锭。”于是国王奖励他10座城邑。第二个仆人报告说：“主人，你给我的一锭银子，我已赚了5锭。” 于是国王例奖励了他5座城邑。第三个仆人报告说：“主人，你给我的一锭银子，我一直包在手巾里存着，我怕丢失，一直没有拿出来。”于是国王命令将第三个仆人的一锭银子也赏给第一个仆人，并且说：“凡是少的，就连他所有的也要夺过来。凡是多的，还要给他，叫他多多益善。”这就是马太效应。   在同类网站中，马太效应是很明显的。一个出名的社区，比一个新建的社区，更容易吸引到新客户。启示是，如果你无法把网站做大，那么你要做专。作专之后再做大就更容易。

5.手表定理

手表定理是指一个人有一只表时，可以知道现在是几点钟，而当他同时拥有两只表时却无法确定。
一个网站，你只需要关注你特定的用户群需求。不要在意不相干人的看法。

6.不值得定律

不值得定律：不值得做的事情，就不值得做好   不要过度seo，如果你不是想只做垃圾站。不要把时间浪费在美化再美化页面，优化再优化程序，在你网站能盈利后，这些事情可以交给技术人员完成。

7.彼得原理

劳伦斯.彼得认为：在各种组织中，由于习惯于对在某个等级上称职的人员进行晋升提拔，因而雇员总是趋向于晋升到其不称职的地位。
不要轻易改变自己网站的定位。如博客网想变门户，盛大想做娱乐，大家拭目以待吧。

8.零和游戏原理

当你看到两位对弈者时，你就可以说他们正在玩“零和游戏”。因为在大多数情况下， 总会有一个赢，一个输，如果我们把获胜计算为得1分，而输棋为-1分，那么，这两人得分之和就是：1+（-1）=0   不要把目光一直盯在你的竞争网站上，不要花太多时间抢它的访客。我们把这些时间用来寻找互补的合作网站，挖掘新访客。

9.华盛顿合作规律

华盛顿合作规律说的是： 一个人敷衍了事，两个人互相推诿， 三个人则永无成事之日。
如果你看准一个方向，你自己干，缺人手就招。不要轻易找同伴一起搞网站，否则你会发现，日子似乎越过越快了，事情越做越慢了。

10.邦尼人力定律

一个人一分钟可以挖一个洞，六十个人一秒种却挖不了一个洞。合作是一个问题，如何合作也是一个问题。你需要有计划。

11.牛蛙效应

把一只牛蛙放在开水锅里，牛蛙会很快跳出来；但当你把它放在冷水里，它不会跳出来，然后慢慢加热，起初牛蛙出于懒惰，不会有什么动作，当水温高到它无法忍受的时候，想出来，但已经没有了力气。   如果你是soho，注意关注你的财务。不要等到没钱了再想怎么挣，你会发现那时候挣钱更难。

12.蘑菇管理

蘑菇管理是许多组织对待初出茅庐者的一种管理方法，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。
  做网站毕竟要遭遇这样的阶段，搜索引擎不理你，友情链接找不到，访客不上门。这是磨练。

13.奥卡姆剃刀定律

如无必要，勿增实体。
把网站做得简单，再简单，简单到非常实用，而不是花俏。google的首页为什么比雅虎好？

14.巴莱多定律(Paredo 也叫二八定律)

你所完成的工作里80%的成果，来自于你20%的付出；而80%的付出，只换来20%的成果。
随时衡量你所做的工作，哪些是最有效果的。

1.马蝇效应

林肯少年时和他的兄弟在肯塔基老家的一个农场里犁玉米地，林肯吆马，他兄弟扶犁，而那匹马很懒，慢慢腾腾，走走停停。可是有一段时间马走得飞快。 林肯感到奇怪，到了地头，他发现有一只很大的马蝇叮在马身上，他就把马蝇打落了。看到马蝇被打落了，他兄弟就抱怨说：”哎呀，你为什么要打掉它，正是那家伙使马跑起来的嘛！”   在你心满意足的时候，去寻找你的马蝇。没有firefox，不会有ie7，firefox就是微软的马蝇之一。马蝇不可怕，怕的是会一口吃掉你的东西，像 ie当初对网景干的那样。

2.最高气温效应

每天最热总是下午2 时左右，我们总认为这个时候太阳最厉害，其实这时的太阳早已偏西，不再是供给最大热量的时候了。此时气温之所以最高，不过是源于此前的热量积累。
你今天的网站流量，是你一个星期或更长时间前所做的事带来的。

3.超限效应(溢出效应)

刺激过多、过强和作用时间过久而引起心理极不耐烦或反抗的心理现象，称之为“超限效应”。 别到别人论坛里发太多广告。别在自己网站上放太多广告。别在自己的论坛里太多地太明显地诱导话题。

4.懒蚂蚁效应

生物学家研究发现，成群的蚂蚁中，大部分蚂蚁很勤劳，寻找、搬运食物争先恐后，少数蚂蚁却东张西望不干活。当食物来源断绝或蚁窝被破坏时，那些勤快的蚂蚁一筹莫展。“懒蚂蚁”则“挺身而出”，带领众伙伴向它早已侦察到的新的食物源转移。   不要把注意力仅仅放在一个网站上，即使这个网站现在为你带来一切。你要给自己一些时间寻找新的可行的方向，以备万一。

5.长尾理论

ChrisAnderson认为，只要存储和流通的渠道足够大，需求不旺或销量不佳的产品共同占据的市场份额就可以和那些数量不多的热卖品所占据的市场份额相匹敌甚至更大。   对于搜索引擎，未必你需要一个热门词排在第一位，如果有一千个冷门词排在第一位，效果不但一样，还会更稳定更长远。

6.破窗理论

栋建筑上的一块玻璃，又没有及时修好，别人就可能受到某些暗示性的纵容，去打碎更多的玻璃。   管理论坛时，如果你发现第一个垃圾贴，赶紧删掉他吧。想想：落伍现在为什么那么多××贴？现在控制比最初控制难多了。

7.“羊群效应”，又称复制原则(Copy Strategy)

一个羊群(集体)是一个很散乱的组织，平时大家在一起盲目地左冲右撞。如果一头羊发现了一片肥沃的绿草地，并在那里吃到了新鲜的青草，后来的羊群就会一哄而上，争抢那里的青草，全然不顾旁边虎视眈眈的狼，或者看不到其它地方还有更好的青草。
不要轻易跟风，保持自己思考的能力。

8.墨菲定律

如果坏事情有可能发生，不管这种可能性多么小，它总会发生，并引起最大可能的损失。
除非垃圾站，否则不要作弊，对搜索引擎不要，对广告也不要。

9.光环效应

人们对人的某种品质或特点有清晰的知觉，印象比较深刻、突出， 这种强烈的知觉， 就像月晕形式的光环一样，向周围弥漫、扩散，掩盖了对这个人的其他品质或特点的认识。
不要轻易崇拜一个人或者公司、一个概念、一种做法。

10.蝴蝶效应

一只亚马逊河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，两周后，可能在美国德克萨斯州引起一场龙卷风。
不管你做什么，网站或者其他，你都应该关注新闻。机遇或者灾难可能就在那。

11.阿尔巴德定理

一个企业经营成功与否，全靠对顾客的要求了解到什么程度。   我赞同别人的点评：看到了别人的需要，你就成功了一半；满足了别人的需求，你就成功了全部。尤其是做网站。

12.史密斯原则

如果你不能战胜他们，你就加入到他们之中去。  
不要试图做孤胆英雄。如果潮流挡不住，至少，你要去思考为什么。

Posted in: web Comments(0) March 2007


PHP5 效率优化

Posted by gavinkwoe

静态调用的成员一定要定义成 static  (PHP5 ONLY)

5 引入了静态成员的概念，作用和 4 的函数内部静态变量一致，但前者是作为类的成员来使用。静态变量和 的类变量( variable)差不多，所有类的实例共享同一个静态变量。

<?
 foo {
    function bar() {
        echo ‘foobar’;
    }
}

$foo = new foo;

// instance way

$foo->bar();

// static way

foo::bar();
?>

静态地调用非 static 成员，效率会比静态地调用 static 成员慢 50-60%。主要是因为前者会产生 E_STRICT 警告，内部也需要做转换。

使用类常量 (PHP5 ONLY)

5 新功能，类似于 ++ 的 const。

使用类常量的好处是：

- 编译时解析，没有额外开销
- 杂凑表更小，所以内部查找更快
- 类常量仅存在于特定「命名空间」，所以杂凑名更短
- 代码更干净，使除错更方便

(暂时)不要使用 require/include_once

require/include_once 每次被调用的时候都会打开目标文件！

- 如果用绝对路径的话， 5.2/6.0 不存在这个问题
- 新版的 APC 缓存系统已经解决这个问题

文件 I/O 增加 => 效率降低

如果需要，可以自行检查文件是否已被 require/include。

不要调用毫无意义的函数

有对应的常量的时候，不要使用函数。

<?
php_uname(’s’) == PHP_OS;
php_version() == PHP_VERSION;
php_sapi_name() == PHP_SAPI;
?>
虽然使用不多，但是效率提升大概在 3500% 左右。

最快的 Win32 检查

<?
$is_win = DIRECTORY_SEPARATOR == ‘\\’;
?>

- 不用函数
- Win98/NT/2000/XP/Vista/Longhorn/Shorthorn/Whistler…通用
- 一直可用

时间问题 (>5.1.0 ONLY)

你如何在你的软件中得知现在的时间？简单，「time() time() again, you ask me…」。

不过总归会调用函数，慢。

现在好了，用 $_SERVER['REQUEST_TIME']，不用调用函数，又省了。

加速 PCRE

 对于不用保存的结果，不用 ()，一律用 (?:)

这样 不用为符合的内容分配内存，省。效率提升 15% 左右。

- 能不用正则，就不用正则，在分析的时候仔细阅读手册「字符串函数」部分。有没有你漏掉的好用的函数？

加速 strtr

如果需要转换的全是单个字符的时候，用字符串而不是数组来做 strtr：

<?
$addr = strtr($addr, "abcd", "efgh"); // good
$addr = strtr($addr, array(‘a’ => ‘e’,
                           // …
                           )); // bad
?>
效率提升：10 倍。

不要做无谓的替换

即使没有替换，str_replace 也会为其参数分配内存。很慢！解决办法：

- 用 strpos 先查找(非常快)，看是否需要替换，如果需要，再替换

效率：

- 如果需要替换：效率几乎相等，差别在 0.1% 左右。
- 如果不需要替换：用 strpos 快 200%。

邪恶的 @ 操作符

不要滥用 @ 操作符。虽然 @ 看上去很简单，但是实际上后台有很多操作。用 @ 比起不用 @，效率差距：3 倍。

特别不要在循环中使用 @，在 5 次循环的测试中，即使是先用 error_reporting(0) 关掉错误，在循环完成后再打开，都比用 @ 快。

善用 strncmp

当需要对比「前 n 个字符」是否一样的时候，用 strncmp/strncasecmp，而不是 substr/strtolower，更不是 PCRE，更千万别提 ereg。strncmp/strncasecmp 效率最高(虽然高得不多)。

慎用 substr_compare (PHP5 ONLY)

按照上面的道理，substr_compare 应该比先 substr 再比较快咯。答案是否定的，除非：

- 无视大小写的比较
- 比较较大的字符串

不要用常量代替字符串

为什么：

- 需要查询杂凑表两次
- 需要把常量名转换为小写(进行第二次查询的时候)
- 生成 E_NOTICE 警告
- 会建立临时字符串

效率差别：700%。

不要把 count/strlen/sizeof 放到 for 循环的条件语句中

贴士：我的个人做法

<?
for ($i = 0, $max = count($array);$i < $max; ++$i);
?>

效率提升相对于：

- count 50%
- strlen 75%

短的代码不一定快

<?
// longest
if ($a == $b) {
    $str .= $a;
} else {
    $str .= $b;
}
// longer
if ($a == $b) {
    $str .= $a;
}
$str .= $b;

// short
$str .= ($a == $b ? $a : $b);
?>
你觉得哪个快？

效率比较：

- longest: 4.27
- longer: 4.43
- short: 4.76

不可思议？再来一个：
<?
// original
$d = dir(‘.’);
while (($entry = $d->read()) !== false) {
    if ($entry == ‘.’ || $entry == ‘..’) {
        continue;
    }
}

// versus
glob(‘./*’);

// versus (include . and ..)
scandir(‘.’);
?>
哪个快？

效率比较：

- original: 3.37
- glob: 6.28
- scandir: 3.42
- original without OO: 3.14
- SPL (PHP5): 3.95

画外音：从此也可以看出来 PHP5 的面向对象效率提高了很多，效率已经和纯函数差得不太多了。

提高 文件访问效率

需要包含其他 文件的时候，使用完整路径，或者容易转换的相对路径。

<?

include ‘file.’; // bad approach

incldue ‘./file.’; // good

include ‘/path/to/file.’; // ideal

?>

物尽其用

有很多扩展和函数可用，在实现一个功能的之前，应该看看 是否有了这个功能？是否有更简单的实现？

<?
$filename = "./somepic.gif";
$handle = fopen($filename, "rb");
$contents = fread($handle, filesize($filename));
fclose($handle);

// vs. much simpler

file_get_contents(‘./somepic.gif’);
?>

关于引用的技巧

引用可以：

- 简化对复杂结构数据的访问
- 优化内存使用
<?
$a['b'][''] = array();

// slow 2 extra hash lookups per access
for ($i = 0; $i < 5; ++$i)
    $a['b'][''][$i] = $i;

// much faster reference based approach
$ref =& $a['b'][''];
for ($i = 0; $i < 5; ++$i)
    $ref[$i] = $i;
?>
<?
$a = ‘large string’;

// memory intensive approach
function a($str)
{
    return $str.’something’;
}

// more efficient solution
function a(&$str)
{
    $str .= ’something’;
}
?>
==============================================
参考资料
http://ilia.ws

Ilia 的个人网站，，他参与的开发以及出版的一些稿物链接等等。
http://ez.no

eZ components 官方网站，eZ comp 是针对 PHP5 的开源通用库，以效率为己任，Ilia 也参与了开发。
http://phparch.com

|architect，不错的 出版商/培训组织。买不起或者买不到的话，网上可以下到很多经典的盗版。

http://talks.php.net

Posted in: doc Comments(0) January 2007


Mysql 优化

Posted by gavinkwoe

7.3 锁

7.3.1 锁机制

当前MySQL已经支持 ISAM, MyISAM, MEMORY (HEAP) 类型表的表级锁了，BDB 表支持页级锁，InnoDB 表支持行级锁。

很多时候，可以通过经验来猜测什么样的锁对应用程序更合适，不过通常很难说一个锁比别的更好，这全都要依据应用程序来决定，不同的地方可能需要不同的锁。

想要决定是否需要采用一个支持行级锁的存储引擎，就要看看应用程序都要做什么，其中的查询、更新语句是怎么用的。例如，很多的应用程序大量的做查询，很少删除，主要是基于索引的更新，只往特定的表中插入记录。采用基本的MySQL MyISAM 表就很合适了。

MySQL中对表级锁的存储引擎来说是释放死锁的。避免死锁可以这样做到：在任何查询之前先请求锁，并且按照请求的顺序锁表。

MySQL中用于 WRITE（写） 的表锁的实现机制如下：