严格的说WebKit仅仅是个浏览器核心，采用该核心的浏览器很多，如国内的搜狗浏览器，遨游浏览器。其他的如google的chrome(Windows平台，linux平台下为chromium),epiphany(linux平台下，gnome2.28版本之后),苹果的Safari 都采用了webkit的内核。Firefox则是采用Gecko的内核，这是NetScape公司开发的内核，后来开源，mozilla继续开发。另外，现在还有另外两种常见的浏览器内核，Trident主要用在IE系列上，Presto主要用在Opera上。
这篇文章仅仅针对浏览器处理JavaScript的性能作比较，主要在X86平台和龙芯平台。先来解释一下JavaScript，JavaScript是互联网内较为常用的脚本语言，面向对象，主要在浏览器内解释执行，用于生成动态网页，因为很多语言特性受Java影响，所以叫JavaScript。通过JavaScript，浏览器可以运行服务器想要在访问者终端上运行的一些计算程序，以达到更好的浏览体验。
再说说浏览器内核和JavaScript的关系，其实JavaScrip脚本的执行仅仅是浏览器内核的一部分，其他的还有Html语言的解释执行，网页的呈现等等也是内核要做的。之所以这么关心浏览器核心对JavaScript脚本的处理情况，是因为现在的很多应用不再是简单的网页浏览，如gmail，google reader，gooe wave还有一些网页3D特效等等都需要在客户机上作计算，这就需要JavaScript大显身手了。而且越来越多的应用依赖JavaScript，所以现在浏览器对JavaScript的处理速度直接影响着用户体验。目前WebKit的JavaScript引擎SquirrelFish，JavaScript的引擎是SpiderMonkey
目前JavaScript在大多数平台上的处理是靠解释执行的，又因为是动态类型，面向对象。。。，决定了JavaScript执行效率低，所以就诞生了各种针对JavaScript的优化，也有了测试JavaScipt解释器性能的BenchMark，目前常用的是Sunspider和google V8，这篇文章中的对比针对Sunspider测试集。
另外还要说说JIT，Just In time，转换，将部分程序代码直接转换成机器码执行，这种技术在运行时优化中比较常用，JavaScript是解释器，所以JIT在解释器中也是很重要的优化手段。目前X86的webkit和Firefox默认就有JIT支持，但龙芯平台上还没有，本博也是最早对龙芯2F平台有JIT支持的Webkit和firefox JavaScript引擎作对比的，目前这两个JIT都还没有进入官方的代码库中，感兴趣的朋友可以在下面的前两个链接中找到相关源码。其中webkit的补丁还要做些宏的修改，改动不大。这两个都是从官方源码库checkout出来并修改之后的。其中firefox的JIT部分是由ZSC大牛写出来的，详细的讨论贴和测试结果可以在龙芯论坛看到，见下面的第三个链接。
x86下epiphany(webkit内核)和firefox开了jit之后的性能，如下
webkit Total: 833.6ms +/- 2.1% firefox Total: 1774.4ms +/- 2.7%
（测试环境是我的笔记本 intel Pentium t2390,开了频率调节，所以波动较大)、两个差距：
TEST COMPARISON FROM TO DETAILS
=============================================================================
** TOTAL **: 2.13x as fast 1774.4ms +/- 2.7% 833.6ms +/- 2.1% significant
=============================================================================
3d: 2.96x as fast 257.2ms +/- 2.1% 87.0ms +/- 1.0% significant
cube: 3.36x as fast 79.2ms +/- 1.7% 23.6ms +/- 2.9% significant
morph: 1.52x as fast 50.4ms +/- 1.4% 33.2ms +/- 3.1% significant
raytrace: 4.23x as fast 127.6ms +/- 3.0% 30.2ms +/- 3.4% significant
access: 3.26x as fast 237.0ms +/- 4.7% 72.8ms +/- 2.8% significant
binary-trees: 8.82x as fast 67.0ms +/- 4.4% 7.6ms +/- 9.0% significant
fannkuch: 3.48x as fast 98.2ms +/- 0.6% 28.2ms +/- 3.7% significant
nbody: 2.50x as fast 51.4ms +/- 10.3% 20.6ms +/- 3.3% significant
nsieve: - 20.4ms +/- 56.6% 16.4ms +/- 4.2%
bitops: 1.42x as fast 53.8ms +/- 1.9% 38.0ms +/- 0.0% significant
3bit-bits-in-byte: *3.10x as slow* 2.0ms +/- 0.0% 6.2ms +/- 9.0% significant
bits-in-byte: - 11.0ms +/- 8.0% 10.4ms +/- 6.5%
bitwise-and: *2.33x as slow* 3.0ms +/- 0.0% 7.0ms +/- 0.0% significant
nsieve-bits: 2.62x as fast 37.8ms +/- 1.5% 14.4ms +/- 4.7% significant
controlflow: 8.76x as fast 50.8ms +/- 2.0% 5.8ms +/- 9.6% significant
recursive: 8.76x as fast 50.8ms +/- 2.0% 5.8ms +/- 9.6% significant
crypto: 2.34x as fast 93.8ms +/- 1.7% 40.0ms +/- 2.2% significant
aes: 2.57x as fast 54.0ms +/- 3.6% 21.0ms +/- 4.2% significant
md5: 2.62x as fast 26.2ms +/- 2.1% 10.0ms +/- 0.0% significant
sha1: 1.51x as fast 13.6ms +/- 5.0% 9.0ms +/- 0.0% significant
date: 1.87x as fast 275.2ms +/- 2.0% 147.0ms +/- 1.0% significant
format-tofte: 2.75x as fast 149.0ms +/- 1.0% 54.2ms +/- 1.0% significant
format-xparb: 1.36x as fast 126.2ms +/- 4.0% 92.8ms +/- 1.7% significant
math: 1.12x as fast 89.8ms +/- 1.8% 80.2ms +/- 21.7% significant
cordic: 2.13x as fast 43.4ms +/- 3.3% 20.4ms +/- 9.2% significant
partial-sums: *1.41x as slow* 34.4ms +/- 2.0% 48.6ms +/- 38.2% significant
spectral-norm: 1.07x as fast 12.0ms +/- 0.0% 11.2ms +/- 12.2% significant
regexp: 3.73x as fast 125.4ms +/- 15.5% 33.6ms +/- 2.0% significant
dna: 3.73x as fast 125.4ms +/- 15.5% 33.6ms +/- 2.0% significant
string: 1.80x as fast 591.4ms +/- 3.3% 329.2ms +/- 1.6% significant
base64: *1.24x as slow* 28.4ms +/- 2.4% 35.2ms +/- 1.6% significant
fasta: 1.71x as fast 133.0ms +/- 2.3% 78.0ms +/- 4.6% significant
tagcloud: 2.81x as fast 169.4ms +/- 3.8% 60.2ms +/- 8.2% significant
unpack-code: 1.91x as fast 193.8ms +/- 4.4% 101.6ms +/- 2.7% significant
validate-input: 1.23x as fast 66.8ms +/- 5.8% 54.2ms +/- 6.4% significant
龙芯上的JIT具体对比数据不便透漏，可以从下面第三个链接中找到第一版发布时的测试数据。这里仅仅给出一个对比。webkit之所以with GUI是使用编译出的迷你小浏览器中测试结果，no GUI是使用测试脚本跑出来的结果。
Webkit with GUI Total: 6723.4ms +/- 0.5% no GUI Total: 6355.8ms +/- 0.5% Firfox Total 7000 ms 左右。
注： 龙芯中的JIT现在还不够成熟，其中Webkit的JIT仅是针对MIPS III做的，没有针对龙芯的特殊优化。
另外，X86中firefox的版本是3.5.7，龙芯中firefox的版本是3.7pre1.WebKit在X86中版本是epiphany的2.28中的版本，龙芯中为SVN中的2010-01-12 r53114。X86运行环境为Gentoo，Gcc4.4.2,Glibc2.11,龙芯运行环境是玲珑一体机，GCC4.3(龙梦修改版）,Glibc2.10。
对比结果可见：X86中WebKit浏览器的性能要明显优于Firefox，达到两倍之多。龙芯相比起来还有些差距，不过相信优化后龙芯的性能会更好。
参考
https://bugs.webkit.org/show_bug.cgi?id=30144
http://dev.lemote.com/code/firefox-3.7-loongson-jit
http://lemote.com/bbs/viewthread.php?tid=26687&extra=page%3D1
http://en.wikipedia.org/wiki/Google_Chrome
http://ineolee.com/pc/several-browser-core-introduction/
请教一下，我的Webkit在Mips上，如果把JIT打开，make jshell会报
JITStubs.cpp:(.text+0×64): relocation truncated to fit: R_MIPS_PC16 against `cti_vm_throw’
这样就没有办法对JIT enable之后做测试。
我所测试的webkit版本比较老一些，现在都半年过去了，估计svn库的代码更新导致了你这个问题。
试过用svn库里较早版本的源码吗？推荐你试试10年2月份左右的代码。估计不会有这个错了。不过2月份的时候mips JIT的补丁还没有进入svn的trunck
[...] Squirrelfish 是Webkit的Javascript引擎。针对龙芯平台(MIPS)已经有了JIT支持，但仅仅对O32系统才有，本博曾经介绍过相关内容（WebKit和Firefox的JavaScript性能对比）。 [...]
[...] WebKit和Firefox的JavaScript性能对比 – 287 views [...]
chromium在我笔记本上的测试结果，相比webkit 833->524 性能高约30%。google的V8引擎不赖。
============================================
RESULTS (means and 95% confidence intervals)
——————————————–
Total: 524.8ms +/- 9.8%
——————————————–
3d: 77.6ms +/- 8.1%
cube: 30.8ms +/- 21.1%
morph: 24.4ms +/- 15.5%
raytrace: 22.4ms +/- 12.2%
access: 50.0ms +/- 13.2%
binary-trees: 3.4ms +/- 55.5%
fannkuch: 18.4ms +/- 10.2%
nbody: 22.0ms +/- 22.2%
nsieve: 6.2ms +/- 32.9%
bitops: 42.6ms +/- 21.0%
3bit-bits-in-byte: 2.8ms +/- 19.9%
bits-in-byte: 9.8ms +/- 5.7%
bitwise-and: 13.0ms +/- 27.9%
nsieve-bits: 17.0ms +/- 53.2%
controlflow: 4.0ms +/- 0.0%
recursive: 4.0ms +/- 0.0%
crypto: 35.2ms +/- 18.9%
aes: 15.4ms +/- 45.9%
md5: 9.0ms +/- 0.0%
sha1: 10.8ms +/- 46.3%
date: 76.0ms +/- 39.8%
format-tofte: 28.6ms +/- 9.0%
format-xparb: 47.4ms +/- 61.3%
math: 47.6ms +/- 6.8%
cordic: 16.8ms +/- 15.2%
partial-sums: 23.0ms +/- 3.8%
spectral-norm: 7.8ms +/- 7.1%
regexp: 23.4ms +/- 4.8%
dna: 23.4ms +/- 4.8%
string: 168.4ms +/- 18.1%
base64: 13.8ms +/- 4.0%
fasta: 26.0ms +/- 53.2%
tagcloud: 39.0ms +/- 2.3%
unpack-code: 62.8ms +/- 58.3%
validate-input: 26.8ms +/- 46.3%
相信JAVASCRIPT的路会越走越远。这些前端程序执行起来再慢应该也比在服务器端效率高。另外FIREFOX已经发布3.6了，据说速度提高了15％。
@王辉, 不太懂，为啥前端程序的执行效率比服务器端高？ 我只是简单的理解为能放在服务器端的程序，绝不放在客户端执行，否则用户体验会因为客户端的运算量过大而降低。
@erlv, 我理解中的前端程序就是指的浏览器端的。我觉得恰恰相反，能放在客户端的一定要放在客户端。如果放在服务器端，数据的传送就会耗去大量的时间。