PHP autoload与include性能比较

自PHP5后,官方大大丰富了对面向对象的支持,其中有个重要改变:引入了__autoload()函数,从此不再需要在php脚本的header写一堆的require或include了,用PHP函数手册中的话说:”它会在试图使用尚未被定义的类时自动调用”。

这一机制大大减轻了开发人员的负担,只要在架构初期考虑好了目录结构和命名规范,在开发过程中,需要再为代码中要用到的类分别去require相应的文件,减少了大量代码。

但这样一来,也容易出现运行一个程序,某个类文件被include多次,例如有以下四个脚本:

1
2
3
#file:include1.php 
include 'include2.php'; 
//@todo something
1
2
#file:include2.php 
//@todo something
1
2
3
#file:script1.php 
include 'include2.php'; 
//@todo something
1
2
3
4
#file:script2.php 
include 'include1.php'; 
include 'script1.php' 
//@todo something

当执行script1.php时, include ‘include2.php’; 这行代码被执行了一次。而执行script2.php时,这行代码被执行了两次。

这里只是一个简单的例子,在实际的项目中,include2.php被include的次数可能更多。这样反复的include,是否会影响性能呢?为此我写了个脚本来测试。

1
2
3
4
5
6
#file:SimpleClass.php
class SimpleClass {
        public function __construct() {
                echo get_time() . "\r\n";
        }
}
1
2
3
4
5
#file:php_include.php
for($i  = 0;$i < $loop;$i++) {
        include_once "SimpleClass.php";
        new SimpleClass();
}

当$loop值为1时,脚本耗时约0.00018906593322754秒,当$loop为1000时,脚本耗时约0.076701879501343秒。

如果我们用autoload实现呢?

1
2
3
4
5
6
7
8
#file:php_autoload.php
function __autoload($class_name) {
        include_once $class_name . '.php';
}
 
for($i  = 0;$i < $loop;$i++) {
        new SimpleClass();
}

在这段代码中,我定义了__autoload函数,几乎一样的脚本,当$loop为1时,耗时0.0002131462097168秒,而当$loop为1000时,耗时仅为前面代码的1/7,0.012391805648804秒。

但请注意看SimpleClass的代码,其中输出了一行字符串,如果去掉这行输出后再比较,会是什么样的结果呢?

在$loop同为1000的情况下,前者耗时0.057836055755615秒,而使用了autoload后,仅仅0.00199294090271秒!效率相差近30倍!

从上面的测试可以看出,当文件仅仅被include一次,autoload会消耗稍微多一点的时间,但如果在文件被反复include的情况下,使用autoload则能大大提高系统性能。

至于是否要使用autoload来解放程序员,这就仁者见仁,智者见智了。在我看来,条件允许的前提下,牺牲这一点性能(某些情况下,可能是提升性能),换来更为便捷的开发,是值得的。

附:本文测试脚本下载

春运有感

《有钱没钱,回家过年》,记得去年有这么一部以春运回家为背景的电影,深刻反映了春运期间一票难求的情况,而今年由于受金融危机的影响,这个问题显得更加突出和严重。

今年是毕业后在外工作的第一个年头,往年这个时候都已经在长沙的家中和同学朋友们闹了,但工作了就不再有那么长的假期,只有短短的7天日子可以用来挥霍。

以往都是学校给统一订票,虽然基本都是硬座,但好歹是不愁回家的票。而走出校园后就不再这么舒服了,凡事都得靠自己。每天早上上班的路上,经过一个个订票点,总能看到长达数十米的购票大队;临近年关的这今天,公司里讨论最多的话题也是火车票,一边骂票贩子缺德,一边在网站上查转让信息打电话咨询,往往在打了多个电话无果后,却又希望能找到一个真正的票贩子。

公司是做分类信息网站,自然火车票也是近期的一大热门板块,在春运期间,为网站带来了不少流量。但今天中午后,却收到了有关部门(话说这是中国最神秘,最NB的部门了)的通知,停止火车票转让信息的发布和展示,据说是为了打击票贩子。

囧,看看日历,今天已经19号了,距离大年三十也只有5天时间而已,这时候打击,受影响的其实仅仅是一些小票贩子,都不知道已经是第几手的票贩子了,对于黄牛票的源头,可以说是无关痛痒了,该卖的票都已经卖的差不多了。而更受影响的,则是一些确实手中有多余票想转让和一些求购者,这下可好,本来还有希望找个票贩子,现在连票贩子都找不着了,存心不让人回家了……

天气预报V2隆重上线测试

相关链接:老版系统 新版系统

当初做RSS天气预报纯属兴趣,完全没有想到提供服务后如此受欢迎,在2008一年时间内,访问量超过千万,平均每日4万多次。这套系统完全没有做过任何宣传,仅仅靠网友们的口碑相传就能达到这么多的访问量,远远超过我的意料之外。另外据我简单的来源统计,至少有3-4款手机客户端软件使用了raychou的RSS作为数据源。

raychou.com里和天气预报程序有关的文章:

网络/网友相关介绍

程序发布2年多,期间重写过一次,再应网友要求增加了ICAL输出,但当时由于GG日历对于外部ICAL中文支持的问题,一直无法在GG日历中完美显示中文,很长一段时间内都是以拼音代替中文输出,以满足网友们利用Google日历的免费短信提醒功能接受天气预报。这一问题在新版系统中也终于得到解决。

随着访问量的上升,以及众多网友在Blog上留言对现有系统的各种不满,利用周末的时间重写了全部代码,并于今天正式对外测试(新版系统网址:http://weather.raychou.com)。新的架构实现了多数据源采集,多格式输出,能够非常方便的进行输出源的扩展,目前已完成RSS和ICAL格式的输出,计划中还有HTML,WAP,Mobile,iPhone等输出格式以满足各类网友的需求。

希望使用老版数据源的用户尽快转到新版,针对v1,v2做了如下改进:

  • 进入系统会自动根据用户ip来源显示当地天气情况
  • 可使用汉字或拼音快速搜索指定地区
  • RSS输出兼容Google阅读器抓虾等主流RSS阅读器
  • ICAL输出完美兼容Google日历

计划中要推出的功能

  • widget,用户可在论坛签名档,blog侧边栏,网站首页等等区域调用代码,实现为访客显示当地天气预报
  • 丰富的输出格式

更多功能期待您的建议,有任何想法欢迎联系我,联系方式请看这里

PS:一如既往,这套系统任然会提供免费下载,我将会第一时间在Blog公布。

我的2008

2008,对于中国人来说是不平凡、不平静的一年,太多的事情值得我们去记忆。

2008,对于我来说也是不同寻常的一年,在这一年,我毕业了,工作了,重返北京了。

2月 三宝殿正式上线,怀胎数月,终于分娩。

5月 俺自己电子杂志网迫于成本压力,上线一年半后,正式关站。

6月 领到了奋斗了5年的毕业证,意料之中的获得了优秀论文和毕设,意外之外的没有任何奖金。

7月 重新回到北京,经过了短暂的内蒙之旅后,开始寻找工作机会。

8月 开始了第一份工作,就职于某分类信息网站。

9月 观看了几场奥运比赛。

10月 工作后的第一次长假,回了一趟家,感觉很不一样了,似乎再次回到这个生活了20多年的城市,我却感觉是个客人。

12月 开始迎接2009

入手铁三角EQ700

飞利浦SHS4700NOKIA BH-320和记Arrow Lite之后,今天又入手了铁三角EQ700

入手EQ700的理由很简单,SHS4700不能收线,每次使用前都要花好几分钟来缕线,尤其在外面使用时很不方便。

一天在网上闲逛的时候意外发现原来厂家已经考虑到这种情况,市面上已经有可以自动收线的耳机,当耳机不使用时,可以自动吧线收入耳机中,需要使用时才抽出来,很是方便。

于是在网上简单搜了搜”收线耳挂耳机“(为什么选择耳挂式?因为觉得耳挂的小巧,比起头戴式耳机,更加方便携带,佩戴也较为舒适),经过一番比较,最后看中了EQ700。

最后在淘宝以188的价格成交(日行盒装),不得不说下EQ700设计上的一个小问题,左右耳机中的收线开关很灵活,按下立刻自动收线,但耳机插孔的收线开关却显得非常生涩,按了半天也收不进去,于是以为卖家发的货有问题,于是联系了卖家上门换货,结果才知道,需要吧耳机插口插到耳机上,再按收线开关就能自动收线了……

客串了一把职场侩子手

周末帮朋友公司面试了几个PHPer,临时赶制了一份笔试题,头一次做面试官。

自己觉得比较基础的东西,却问倒了一多半的人。

挺爽的,下回还要做。

UCHome二次开发规范 – 不同于Manyou的开发模式

注意:此文和UCHome的Manyou开发模式不同,Manyou是利用Discuz的开放平台MYOP开发公共插件,可供所有基于UCHome的网站使用;而此文涉及的开发模式与Manyou不同,是在本地开发,以插件的形式扩展UCHome原有功能。

UCHome是Discuz的一款SNS程序,能让每个网站都用拥有自己的Facebook/校内。Discuz也提供了MYOP开发者平台,所有开发者都可以在此平台上开发自己的应用程序供其他UCHome网站使用,不但可以为自己的网站增加功能,同时也能将自己网站的功能推广到数以万计的UCHome网站中,可谓一举两得。

有时候,开发者并不一定希望使用MYOP开发应用,一是由于产品的需要,并不希望开发出来的应用被其他网站使用;二者MYOP的开发,必须处理联网模式,不能本地开发,较为繁琐。因此,很多有能力的站长会在UCHome的基础之上,以修改UCHome代码的方式增加功能。

但UCHome发展速度很快,经常会有版本更新,往往这个时候,修改了UCHome源码的站长就会面临一个两难的问题:是升级程序?还是为了保留以往的修改,而不升级?在我看来,如果前期做好开发规范,是完全可以避免这个问题的。下面介绍一下我在UCHome Apps开发过程中的一些经验。

想要能够随着官方的程序发布实现平滑的代码升级,无非一点:尽量的少改UCHome原有代码。

少改,但不是不改。一点不改程序的源代码是不可能的。但如何能实现少改呢?我定制了了下面的一些规则:

Read the rest of this entry »

Adobe CS4

我不是设计师,AdobeCS套件中对我用处最大的也就只有Dreamweaver,但我装了PS和FW,却没有装DW……

因为自从开发平台转到Eclipse后,已经习惯所有的开发工作都在Eclipse中完成,完全抛弃了DW,但偶尔需要改改图片,所以PS自然是少不了,而FW主要是用来做GIF动画(我是PS小白,PS好像做不了多帧GIF?)。

CS4相比CS3,界面变化非常大,仅仅从两者的工作区就能比较出来,CS3已经卸载了,大家可以看看CS4的界面

启动界面,和往常的版本区别不大

工作区,很明显的变化是没有了往常菜单栏上的那根蓝条(不知道该叫什么)

据说CS4中PS加入的3D相关的功能,不过体积也是暴涨,1.6G……

MySQL分卷备份/导入工具

相信很多使用虚拟主机,没有SSH权限的站长们,最郁闷的一件事就是MySQL数据的备份和导入,几兆大小的数据文件还好说,但经常有动辄几十上百兆的数据需要导入导出,phpmyadmin可以方便的导出大量数据,但对于大文件的导入却无能为力。

下面推荐的一款”PHP版MySQL数据库分卷备份工具”,可以轻松胜任超大数据库的备份/导入工具,最重要的是,他可以分卷操作,并可以指定每个文件的大小。

需要输入密码验证才能进行操作

分卷备份

分卷导入,只要导入一个文件,会自动导入其余分卷

官方下载

彻底屏蔽百度

最近闹得满城风雨的百度竞价门相信不需要我多说,大家都有所了解,也是由于百度竞价排名的原因,最近几年,主要都是用google来搜索,但由于baidu比google打起来更加顺手,我经常还是习惯性的打开百度。自从竞价门事发之后,一直想着怎样改掉这个习惯,终于琢磨出下面这个办法:

(中心思想:通过hosts文件在本地做DNS解析,吧baidu的域名指向google)

1.点击”开始”,”运行”或者win+r,输入cmd;

2.输入ping www.google.com

2008-11-22_141549.jpg

其中的208.67.219.230为你当地访问google最快的IP地址,各地不一样,我使用的是opendns

3.用记事本打开C:\WINDOWS\system32\drivers\etc\hosts文件,在最后加上两行:

208.67.219.230 baidu.com
208.67.219.230 www.baidu.com

其中208.67.219.230换为第二步中取到的google的ip地址

再打开浏览器试试看,是不是访问www.baidu.com就自动跳转到google了?恭喜恭喜。