说这句话,意思是Swing可以快过SWT,而且事实已经证明了这一点。MiG Layout Site网站的Mikael Grev曾编写了一个GUI benchmark,来测试和比较Swing和SWT的性能,最终结论是除在Windows上Swing和SWT的速度几乎一样快之外,在其他操作系统上 Swing的速度都要快于SWT。
这好像违背人们的常识,模拟的组件如何能快过本地组件?实际如果你按照下面的想法想,这个现象也就不难解释:
1. 本地组件实际上也是画出来,只不过是操作系统画罢了。这个通常是人们所忽略的,仿佛只有Swing是画出来的,而本地组件就是屏幕上的附属物似的,忘记了它们也是画出来的。
2. 现在Java平台的运行速度已经不慢于C/C++等静态编译型语言的产生的代码。人们往往提到本地仿佛就比Java实现要快。在过去也许可以这样看,但是 现在随着Java 6平台性能的提高,许多地方Java平台的速度反而快过本地调用。因此是应该让人们从过去对于Java速度的印象中醒过来时候了,现在人们提到Java速 度想到的应该是和C/C++相提并论了。
3. JNI调用耗费的时间是不能忽略的。JNI调用速度要比普通Java方法调用慢好几倍甚至几十倍。即便是在Java 6中,这种情况并没有改善。问题的实质在于Java运行时系统和本地库之间毕竟是两个异质系统,它们之间的调用必然有大量的转换开销。Java普通方法调 用和JNI调用之间的关系就好像是本地调用和远程过程调用之间的区别,远程过程调用有网络数据通信和数据类型系统转换的开销,而JNI也有数据传递(主要 是内存拷贝,速度虽然快过网络通信,但是相对直接调用是不能忽略的)和数据类型系统转换(Java数据类型和C语言数据类型)的开销。
4. Swing绝大部分是用Java平台模拟出的组件,这个过程都在一个系统平台内完成。而SWT是部分在本地系统完成,部分在Java平台完成,要在这两个平台之间需要进行频繁的数据交互。
5. Swing可以享受JVM的特殊待遇,进行特殊优化,比如inline,JIT代码,Swing事件队列对于事件的预处理(合并Paint事件,批处理Java 2D光栅指令等),这就像本地组件可以利用操作系统进行优化一样。
因此如果排除人的因素,也就是说排除Java平台的工程师、Windows的工程师、Linux的工程师和Solaris的工程师本身能力的区别,从理论上来说,Swing的速度是完全可以超过SWT的。理解这一点你只要记住最关键的两个原因是:
1. Java平台的速度可以和C/C++一样快。这个已经被很多benchmark证明了,它们的速度是相当的。因此Java模拟组件不一定会慢过本地组件,这要看谁的实现算法好。
2. 跨系统之间的调用(JNI调用)开销是不能忽略的。这个也在很多论文和benchmark得到证明。Swing中组件和数据之间的更新速度要远快于 SWT,其原因就是Swing不需要进行数据传输,而SWT需要跨两个系统进行数据传输。这在大数据量编辑组件如Table中尤其明显。原因就在于 Swing直接显示了数据模型,而SWT需要将这些数据使用JNI发送到本地组件中去。
不可否认,Microsoft在Windows上浸淫了这么多年,图形用户界面的优化已经非常完善,而反观Linux和Unix系列的桌面系统却没有如此 优化过。这就是为什么前文的benchmark显示SWT能在Windows上和Swing速度相持平,而在其他平台上远慢于Swing的原因。因为 SWT使用本地组件,它既占了Windows的光,也因此吃了Linux和Unix的亏。
这好像违背人们的常识,模拟的组件如何能快过本地组件?实际如果你按照下面的想法想,这个现象也就不难解释:
1. 本地组件实际上也是画出来,只不过是操作系统画罢了。这个通常是人们所忽略的,仿佛只有Swing是画出来的,而本地组件就是屏幕上的附属物似的,忘记了它们也是画出来的。
2. 现在Java平台的运行速度已经不慢于C/C++等静态编译型语言的产生的代码。人们往往提到本地仿佛就比Java实现要快。在过去也许可以这样看,但是 现在随着Java 6平台性能的提高,许多地方Java平台的速度反而快过本地调用。因此是应该让人们从过去对于Java速度的印象中醒过来时候了,现在人们提到Java速 度想到的应该是和C/C++相提并论了。
3. JNI调用耗费的时间是不能忽略的。JNI调用速度要比普通Java方法调用慢好几倍甚至几十倍。即便是在Java 6中,这种情况并没有改善。问题的实质在于Java运行时系统和本地库之间毕竟是两个异质系统,它们之间的调用必然有大量的转换开销。Java普通方法调 用和JNI调用之间的关系就好像是本地调用和远程过程调用之间的区别,远程过程调用有网络数据通信和数据类型系统转换的开销,而JNI也有数据传递(主要 是内存拷贝,速度虽然快过网络通信,但是相对直接调用是不能忽略的)和数据类型系统转换(Java数据类型和C语言数据类型)的开销。
4. Swing绝大部分是用Java平台模拟出的组件,这个过程都在一个系统平台内完成。而SWT是部分在本地系统完成,部分在Java平台完成,要在这两个平台之间需要进行频繁的数据交互。
5. Swing可以享受JVM的特殊待遇,进行特殊优化,比如inline,JIT代码,Swing事件队列对于事件的预处理(合并Paint事件,批处理Java 2D光栅指令等),这就像本地组件可以利用操作系统进行优化一样。
因此如果排除人的因素,也就是说排除Java平台的工程师、Windows的工程师、Linux的工程师和Solaris的工程师本身能力的区别,从理论上来说,Swing的速度是完全可以超过SWT的。理解这一点你只要记住最关键的两个原因是:
1. Java平台的速度可以和C/C++一样快。这个已经被很多benchmark证明了,它们的速度是相当的。因此Java模拟组件不一定会慢过本地组件,这要看谁的实现算法好。
2. 跨系统之间的调用(JNI调用)开销是不能忽略的。这个也在很多论文和benchmark得到证明。Swing中组件和数据之间的更新速度要远快于 SWT,其原因就是Swing不需要进行数据传输,而SWT需要跨两个系统进行数据传输。这在大数据量编辑组件如Table中尤其明显。原因就在于 Swing直接显示了数据模型,而SWT需要将这些数据使用JNI发送到本地组件中去。
不可否认,Microsoft在Windows上浸淫了这么多年,图形用户界面的优化已经非常完善,而反观Linux和Unix系列的桌面系统却没有如此 优化过。这就是为什么前文的benchmark显示SWT能在Windows上和Swing速度相持平,而在其他平台上远慢于Swing的原因。因为 SWT使用本地组件,它既占了Windows的光,也因此吃了Linux和Unix的亏。