市面上有一大堆的JavaScript引擎（光是浏览器所常用的那些就已经够多的了）：

1.         JavaScriptCore：Safari/WebKit（Safari 3.1以前的版本）用的是这个引擎。

2.         SquirrelFish：该引擎用于Safari 4.0。注意：最新的WebKit nightly for Windows在Dromaeo测试中会崩溃，所以暂时就无视它吧。

3.         V8：该引擎用于Google Chrome。

4.         SpiderMonkey：Firefox（Firefox 3.0或更早的版本）用的是这个引擎。

5.         TraceMonkey：3.1以及更高版本的Firefox将使用这个引擎（现在已经有了，只是默认被禁用了而已）。

6.         Futhark：该引擎用于Opera 9.5及其更高版本中。

7.         IE Jscript：Internet Explorer用的就是这个引擎了。

关于上述浏览器的性能测试已经有很多了，其中有些测试还包括了刚出锅的Chrome。我们很有必要仔细地研究一下这些测试，并尝试找出它们所关注的测试目标及其测试结果具体对应于哪些实际的网页性能。

本文将要讨论的测试平台有以下三种：

SunSpider：它是较为流行的JavaScript性能测试平台，由WebKit团队开发；仅测试JavaScript引擎（不含渲染及DOM操作）的性能；拥有许多的测试类型（如对象、函数调用、数学、递归……等等）。

V8 Benchmark：它是由V8团队开发的一种性能基准测试平台，仅测试JavaScript性能（尤其关注递归的性能测试）。

Dromaeo：该测试平台由Mozilla开发，用于测试JavaScript、DOM以及JavaScript Library的能；拥有大量的测试类型，其中大部分用于分析DOM和JavaScript库的性能。

SunSpider

我们先来看看WebKit的SunSpider测试结果（它有着大量的纯JavaScript功能）。下图为详细的测试结果：

可以发现，这是一条由Chrome开始逐步向上的曲线（无视早期的Internet Explorer）。显然，Chrome是最快的（不过，这里并没有包含针对TraceMonkey引擎的测试结果）。

昨天晚上，Brendan Eich将最新的TraceMonkey代码搞了出来，并把它跟V8放在一起做了个比较。

可以发现，TraceMonkey（开发了约两个月）的性能要比V8（开发了约两年）好一些。

这里，TraceMonkey的最大问题在于其递归回溯的能力。目前，递归调用时还没有任何的回溯（这就使得TraceMonkey在递归时要比V8慢差不多10倍）。当递归回溯功能加入到Firefox 3.1之后，我相信上面那个结果仍然会出现的。

Google Chrome Benchmark

Chrome团队发布了他们自己的用于分析JavaScript性能的测试平台。它含有一些新的测试（即不同于SunSpider的那些），而且有着非常变态的递归：

通过这些测试，我们可以发现Chrome直接秒杀了其他浏览器。这些测试是否能够说明真实的浏览器性能呢？这个问题还是有待商榷的，因为它只是高度关注了JavaScript中的一些细节功能而已。

注意，TraceMonkey表现得很差：由于没有递归回溯，因此它在这里占不到任何便宜（就像前面所解释的那样）。

Dromaeo with DOM

最后，我们来更全面地看看JavaScript的性能。我一直在维护Dromaeo测试平台，已经添加了大量新的DOM和JavaScript库测试。它能够提供更加权威的浏览器性能报告，即关注浏览器在进行正常的Web浏览时的性能表现。

考虑到大部分网页都受制于DOM的性能（想想table sorter之类的东西就明白了）而不是JavaScript的性能（如游戏、图形等），因此很有必要仔细看看这些扩展分析的结果。

针对JavaScript、DOM以及库测试的分析结果（多谢Asa Dotzler帮我搞掂了这些测试）：

（比较郁闷的是，这里没有IE的测试结果，因为该浏览器在测试时崩溃掉了。另外，我在Windows上运行WebKit的各种nightly版本（包括Squirrelfish）时也遇到了麻烦，参见Bug 20626。）

这里，我们看到了一张非常不同的图。基于WebKit的引擎都有着绝对的领先优势，而Chrome则仅次于最新版的Safari。跟一般的Firefox相比，使用了TraceMonkey的Firefox会有小幅的性能提升。在回溯被应用到DOM结构操作上之前，其全部的潜力是发挥不出来的（其实它现在根本就没这本事，估计要等到Firefox 3.2才行）。

有一件事是明摆着的：JavaScript性能的“跳蛙游戏”仍在继续（译者注：老外小时候会玩这游戏，貌似俺们小时候玩的是“跳马”，规则跟这个差不多。如果理解不了这个意思的话，请google一下leapfrog）。只要有多个JavaScript引擎存在，这种“三十年河东三十年河西”的现象就只会越来越快（显然，这对于最终用户和应用程序开发人员来说，都无疑是一件大好事）。

最近准备丰富一下我这个已经荒废多时的博客了，都差不多长出蘑菇来了……

可惜的是，今后说不定不再从事编程方面的工作了，唉……世事难料啊……

专辑曲目
01 Origin
02 Whisper
03 Imaginary
04 My Immortal
05 Where Will You Go
06 Field Of Innocence
07 Even In Death
08 Anywhere
09 Lies
10 Away From Me
11Eternal


下面附上VeryCD上面的简介： 

其实这张专集的确十分难找，因为Evanesence似乎一直在对它做着冷处理，对外并没有宣传，在唱片店找到的希望为0，就算是原盘也是极其稀有的。而且这张专集各个资料中记载的并不相同，有的说是10首，有的说是12首。对这张专集我不多说什么，大家自己下来听听吧。只要你喜欢《Fallen》，那么《Origin》就不会让你失望。

Evanesence创始人是女主唱Amy Lee和吉他手Ben Moody。两人初次相识是在几年前的一次青年夏令营中，当时吉他手Ben Moody已小有名气，而Amy Lee当时还只是一名普通的夏令营营员。在一次夏令营的集体娱乐活动中，Ben Moody第一次见到了Amy Lee。当时营员们都在一个大型的体育馆中，Ben Moody正坐在地上看其他的营员在打篮球。而在体育馆的另一侧是一个放着钢琴供营员们表演的一个小舞台。就在Ben Moody感到无聊之际，他忽然听见有人在用钢琴谈奏Meatloaf的《I Would Do Anything For Love》，于是就向钢琴望去，只见一个女孩在自如的演奏着自己创作的一些歌曲。Ben Moody被Amy Lee精湛的技艺和那天籁般的嗓音震撼了，在内心深处，Ben Moody已经认定：没有比她更适合的搭档了。不久之后，随着两人互相了解的逐步加深，Ben Moody和Amy Lee便开始用Evanesence这个名字录制一些歌曲。如：《Give Unto Me》和《Understanding》。两人的金属风格也逐渐形成，这种风格在Goth Metal应该属于Ethereal(仙乐)派。

乐队第一张EP唱片于1998年12月乐队第一次在Vino演出时发行，100多张唱片当晚被狂热的乐迷抢购一空。由于女主唱Amy Lee的个人实力，以及乐队独特的风格，使乐队此后颇受欢迎。随着乐队的日渐成熟，Evanesence于2003年3月4日推出了这张处女唱片。

 

 

[新闻]13款Firefox Gmail扩展
博客园首页 社区 新闻频道 小组 博问 网摘 闪存]]>

好了，来看一个例子。广本的冲压科里面，有几台巨型的冲压机，它们外观是一摸一样的，其实功能也一样，都是用来将钢板冲压成型的，但它们生产的产品却不一样，有的生产车顶，有的生产车门，有的生产发动机盖……冲压机的生产厂家不会管你生产什么东西的，只是给你这样一台冲压机，要生产什么完全由你自己放进不同的模具而已。也就是说，广本要某台冲压机生产Fit的车门的话，只需要将Fit的车门模具放入其中就可以了，冲压机不会管什么模具的，只管哐当哐当的压就是了。

来看一个类图。


 

图中，我们可以看到，拥有不同模具的冲压机可以生产不同的产品。而且，冲压机在投入生产之前并不知道它要生产什么东西，只有在给定了模具后才知道要生产什么东西。好了，我们来看看把类图转换成代码的样子。

FactoryMethod


    public abstract class Part
    {
    }

    public class Door : Part
    {
    }

    public class Chassis : Part
    {
    }

    public abstract class Punch
    {
        protected void DoPunch()
        {
            // TODO: do some punch
        }

        public abstract Part Manufacture();
    }

    public class DoorPunch : Punch
    {
        public override Part Manufacture()
        {
            return new Door();
        }
    }

    public class ChassisPunch : Punch
    {
        public override Part Manufacture()
        {
            return new Chassis();
        }
    }

说白了，抽象工厂就是由工厂方法组成的（这个表达也许不够准确）。抽象工厂主要用于创建一系列相关的产品；而工厂方法则主要用于让某一个类处理不同的产品，且这个产品是由子类来决定的。在冲压机的例子中，没有模具的冲压机就是一个抽象类，加上模具就是一个具体的子类的，而模具的抽象就是工厂方法，加上不同的模具就等于为冲压机实现了不同的子类。

还是拿广本来打比方。广本的四个车间，最开头的是冲压科，而在冲压科的门口有一间小房子，里面放了一台激光焊接机，它用它的机械手臂抓起旁边放着的各种各样的钢板，不停的焊接。可能有人要问，这是什么例子？这就是生成器！一般来说，汽车各处外壳的厚度以及硬度是不同的，比如车头部分就要够硬（用来撞的^_^），其他一些地方比如车顶就没有必要用超厚的钢板。这样，一来可以降低整车的质量，可以省油；二来可以降低成本（所以广本暴利啊～～其实其他汽车厂家也这么干）先前所讲的焊接机就是干这个事情的，它将各种不同厚度不同硬度的钢板焊接在一起，供那些巨型的冲压机来冲压成型，以生产汽车的各个不同的部分。各种汽车所使用的合成钢板的组成是不一样的，但冲压机不管那么多，它只管压钢板。这样一来就明白了吧？焊接机将各种钢板按照规定焊接成不同组成的合成钢板，至于它是如何焊接的以及合成钢板的组成，冲压机对这些信息是不关心的。

我们来看一个类图。

这张简单的类图跟《设计模式》书中有显著的不同。因为我主要是用来说明上面的例子的，跟书中提及的例子不同。这个图中，焊接机由焊接程序控制，以生产不同规格的钢板，冲压机仅仅是调用焊接机的GetSteel方法来获得焊好的钢板。其实，这样的情况在我们平时的程序中用得更多一些，即某一个类仅仅是要得到一个产品，而产品的一切信息它均不知晓。当我们需要另外一种规格的钢板时，更换相应的程序就可以了。

在MS给我们的类库中，有一个叫做StringBuilder的类，这就是一个例子。我们给它不同的字符串或是其他对象（这些就可以看作是原材料），根据我们输入的顺序（组装过程），我们可以得到我们想要的一个字符串。

把这个类图串换成代码（这个代码实在不怎么样，还好，这只是一个说明，如果我在工作中写出这样的东西来，我就可以体验一下从17楼飞下的感觉了，^_^）

Builder
    public class Steel
    {
        public object Part00;
        public object Part01;
        public object Part10;
        public object Part11;
    }

    public class WeldingProgramme
    {
        object[] _materials;
        public WeldingProgramme()
        {
            this._materials = new object[4];

            // TODO: Add some materials
        }
        public Steel Go()
        {
            SteelWelder sw = new SteelWelder();
            foreach(object m in this._materials)
            {
                sw.WeldSteel(m);
            }

            //    you can weld the steel like this
            //    sw.WeldSteel(this._materials[3]);
            //    sw.WeldSteel(this._materials[2]);
            //    sw.WeldSteel(this._materials[1]);
            //    sw.WeldSteel(this._materials[0]);


            //    also, you can do it like this
            //    sw.WeldSteel(this._materials[2]);
            //    sw.WeldSteel(this._materials[1]);
            //    sw.WeldSteel(this._materials[0]);
            //    sw.WeldSteel(this._materials[3]);