In the past six years or so the claim that Java is a slow language has regularly appeared in articles and news discussions. Most of the time I follow the debate, but after a while I get bored because the discussions remain at the micro-benchmark level. It continues to amaze me that there isn't more focus on system-level performance in discussions of language performance.
Having spent seven years actively interested in the field of runtime system optimization and the past four years designing a server-side JVM, JRockit, I am pretty convinced that micro-benchmark results cannot be extended to the system level, where performance really matters. Thus, I thought it would be interesting to give you a view of the performance issue from a JVM developer perspective. I'm arguing that Java is anything but a slow and inefficient language, and that the JVM is the key component ensuring that the system is as fast and easy to deploy and run as it was fast and easy to develop.
Performance Is Not a Micro-Benchmark
This is 2002 and people are still arguing that Java is a slow language. The most common argument comes from developers who have written small benchmarks in Java and then rewritten them in C and are touting how much faster the C programs are. I'm not writing this article to claim that they are wrong.
Of course they can write micro-benchmarks in a couple lines of Java code and redo the same benchmarks in C/C++ and the C programs will probably run faster than the Java programs. That's not where I disagree with them. I disagree with their conclusion; the results of a small micro-benchmark test cannot be extended to say anything about a large-scale application. I believe most systems will be built faster by fewer developers and they will even run faster if they are written in Java instead of C. Java is a language of scale; C is a language of micro-level performance. The development of Java is a natural result of the evolution of system development.
The System Development Evolution: From Punch Cards to Web Services
What has happened during the past 30 years or so is an explosion - the explosion of large-scale system development. There are so many developers in the world now, and they're building systems that are larger than what anyone imagined possible 30 years ago. In addition, application development today is no longer an I-build-every-part-of-the-application-myself process. People use standard libraries, frameworks, application servers, and most recently, Web services, to build their applications.
The components are getting bigger and bigger and more and more general. These building blocks, which were once looked upon with disbelief and mistrust, are now taken for granted. However, using these general building blocks has a price: performance. We have traded performance for significantly reduced development time and system complexity. At least that's what we think and what our early measurements indicate. What if we're wrong?
Enter Java and JVMs
The beauty of Java from a large-scale application performance perspective is in two features that are very crucial to performance for large-scale systems: type information and a runtime system (the JVM). The type information is needed by the code generator to discern who calls who, and who points to who. As a result more information can be extracted from a Java program than from a C program, if the compiler is smart. The end result is, of course, higher performance. The JVM is the vehicle for dynamic optimization. The JVM can analyze the behavior of the application and adapt itself and the generated code to the application.
The beauty of this runtime optimization approach is that for the first time ever, the whole system can be optimized specifically for how it is used without having the source code. This is the opportunity. The framework developer can build a general framework that gets used by application developers and that gets optimized specifically for each application that uses the framework. The general building blocks are broken down and melt into each other at runtime. It is the responsibility of the JVM to do this melting. The JVMs, including JRockit, have not reached that goal...yet.
When Dynamic Optimization Really Pays Off
Let me give you another example of the benefits of dynamic optimization. Look at Intel's new 64-bit platform, the Itanium Processor. Its characteristics are novel and enticing. Nevertheless, its EPIC architecture puts very high pressure on the compiler. EPIC means that the compiler has to choose which instructions should be executed in parallel. Most normal processors today do that selection automatically in their out-of-order execution engine. Because the EPIC-based CPUs need to make fewer decisions, they increase the computational efficiency. The caveat is that the compiler has to make intelligent decisions for the performance to increase.
Given all this pressure on the compiler, you might think that EPIC architecture is well-suited for static compilation and that it virtually eliminates the need for a dynamic runtime system. I believe we'll be able to show you in the coming years how totally opposite the reality is. The reason is that the devil is in the details: for the compiler to be able to parallelize code in a good way requires more than knowing the instructions of the program. The compiler has to know two more things: the flow of the program, and the values that are passed around and used in different contexts.
A static compiler doesn't have this runtime information; it cannot tell what parts of the program are executed frequently or what values are commonly passed to a function from a specific call site. A dynamic runtime system, e.g., a JVM, is the easiest kind of system to collect and take advantage of such information. Consequently, I expect to see exciting gains during the next two years for the Itanium-based JVMs. There is a possibility that they'll catch up with and supercede the profile-guided C compilers on EPIC platforms. Because it lacks type information and a runtime system, C is inferior to Java for EPIC architecture.
The JVM - The Glue for the Building Blocks
BEA acquired JRockit in February of this year, and we are now working to integrate JRockit into the BEA product line, making sure that it works well with all of the different BEA products. Bringing the building blocks and glue under the same roof makes your system more manageable and scalable and makes it run faster. The JRockit JVM is becoming an important piece of the BEA WebLogic Platform.
In conclusion, I still expect to see a lot of micro-benchmarks out there comparing Java and C programs, but I hope I've convinced you that using runtime systems like Sun Microsystems' HotSpot or BEA WebLogic JRockit Java is not slow or inefficient, and that the performance of a large-scale system built with Java may be superior to that of the same system built using C.
Copyright © 2002 SYS-CON Media, Inc.
http://www.edunet.com/elt
主题Q是一个全方位的学p作ؓW二语言的网?BR>功能Q聊天室Q语法讲解，l习Q小试Q成语讲?BR>特色Q特别深入地介绍了语法，听力Q沟通技巧等
对象QESL教师和学p人士
《世界日报》北版-生活语
http://www.chineseworld.com/publish/37_9999.r/r.htm
主题Q生zd和实用化的英语网?BR>功能Q分主题讲解p的实用方法，q有母语非英语h士闹的语aW话
特色Q灵zȝ动，有许多实?BR>对象Q英语基教好的h?BR>
http://www.englishtown.com
主题Q是目前|上最有深度的p学习|站
功能Q非常好的语法讲解，l习Q和阅读材料
特色Q正宗英国英?BR>对象Q学p人士
http://www.english-at-home.com/
主题Q是一个全方位的学p作ؓW二语言的网?BR>功能Q聊天室Q语法讲解，l习Q小试Q成语讲?BR>特色Q特别深入地介绍了语法，听力Q沟通技巧等
对象QESL教师和学p人士
http://www.englishbaby.com/
主题Q是一个年Mh学习交流的美国英语网?BR>功能Q每天不同的|上评Q以国行文化Z?BR>特色Q可以学到很多美国俚语和方言
对象Q面向年Mh
http://www.englishclub.net/
主题Q丰富齐全的商业性英文网?BR>功能Q语法讲解，l习Q参考资料，教师材料
对象QESL教师和学p人士
http://www.englishpage.com/index.html
主题Q针对英文基较好的学习h士和教师的网?BR>功能Q阅读，游戏。语法讲解，讨论{?BR>特色Q深入讲解了时态用法，每周有新评推出Q旧评可以在存中扑ֈ
对象QESL教师和学p人士
http://members.home.net/englishzone/index.html
主题Q非商业性英文学习网?BR>功能Q语法讲解，l习Q小成语讲解Q英文笑话，阅读和写?BR>对象Q学p人士
http://www.homestead.com/ESLflow/Index.html
主题Q内容组l得很好的英文网?BR>功能Q语法讲解，口语Q英语对话，阅读和课E安?BR>特色Q用程囄方式讲解p语法概念
对象QESL教师和学p人士
http://www.eslhouse.com/
主题Q内容广泛，参考资料甚?BR>功能Q大量词汇讲解，评安排和参考资?BR>特色Q多媒体中心可播放课E?BR>对象QESL教师和学p人士
http://www.eslpartyland.com/default.htm
主题Q自学和互相交流
功能Q?5个互动式试?5个论坛，让学生互怺，教师可以下蝲评材料
特色Q互动式
对象QESL教师和学p人士
http://gwis2.circ.gwu.edu/~gwvcusas/
主题Q由George Washington University的Professor Christine Melonil护的ESL链接|页
功能Q有学多学习p的链?BR>对象QESL教师和学p人士
http://www.ToLearnEnglish.com
主题Q内容广泛，资源丰富Q值得一?BR>功能Q聊天室Q语法讲解，l习Q小试Q图片，论坛
特色Q做完练习可以得到评语，老师可以在线制作试题
对象QESL教师和学p人士
http://deil.lang.uiuc.edu/
主题Q包括了|上学英语的一些最基本的内?BR>功能Q语法讲解，l习Q互动式3听力训练Q笔友交换，教师参?BR>对象QESL教师和学p人士
http://www.longman-elt.com/index.html
主题Qؓ中国朋友所熟知的朗D语教学方?BR>功能Q测试，专题文章Q链接，窍?BR>对象QESL教师和学p人士
http://www.parlo.com/index.asp
主题Q学语言的网?BR>功能Q对语言l构Q国际文化作出探?BR>特色Q教你怎样学语aQ而不仅是p
对象QESL教师和学p人士
http://www.peakenglish.com
主题Q在U的q程p学习|站 功能Q词汇，阅读Q听?用REALAUDIO)Q语法课E，
特色Q所教英语是用于国?BR>对象Q学p人士
http://schmooze.hunter.cuny.edu:8888/
主题Q英语学习个|站Q可以一对一或分组q行对话
功能Q在U字典，语言游戏QUSENET
对象Q学p人士
http://members.tripod.com/~towerofenglish/index.htm
主题Q非常友好的英文学习|站
功能Q设计专业的|站Q大量的有用资源
对象Q学p人士
非常不错Q大多数是英语教学的p|站Q国内网站其实学p的都不错Q而且一些英语听力和口语的网站还有不，特别是那些VOA{原声听力网站?BR>博客|址中还有一些：
http://wz.blogchina.com/2650405/index.htm
可以参考。比如这?http://www.unsv.com
是英语听力的好帮手?
javaGrowing 2005-10-25 14:23 发表评论
]]>1?http://java.sun.com/ (英文)
Sun的Java|站Q是一个应该经常去看的地方。不用多说?
2、http://www-900.ibm.com/developerWorks/cn/
IBM的developerWorks|站Q英语好的直接去英文ȝ点看。这里不但是一个极好的面向对象的分析设计网站，也是Web ServicesQJavaQLinux极好的网站。强烈推荐！Q！
3、http://www.javaworld.com/ (英文)
关于Java很多新技术的讨论和新闅R想多了解Java的方斚w面的应用Q这里比较好?
4、http://dev2dev.bea.com.cn/index.jsp
BEA的开发者园圎ͼBEA作ؓ最重要的App Server厂商Q有很多独到的技术，在Weblogic上做开发的朋友不容错过?
5、http://www.huihoo.com/
灰狐动力|站Q一个专业的中间件网站，虽然不是专业的Java|站Q但是在J2EE企业应用技术方面有深厚的造诣?
6、http://www.theserverside.com/home/ (英文)
TheServerSide是一个著名的专门面向Java Server端应用的|站?
7、http://www.javaresearch.org/
Java研究l织Q有很多优秀的Java斚w的文章和教程Q特别是在JDO斚w的文章比较丰富?
8、http://www.cnjsp.org/
JSP技术网站，有相当多的Java斚w的文章和资源?
9、http://www.jdon.com/
Jdon论坛Q是一个个人性质的中文J2EE专业技术论坛，在众多的Java的中文论坛中QJdon一个是技术含量非帔RQ帖子质量非常好的论坛?
10、http://sourceforge.net/
SourgeForge是一个开放源代码软g的大本营Q其中也有非帔R怸富的Java的开放源代码的著名的软g?
11. http://www.matrix.org.cn
javaGrowing 2005-09-12 09:58 发表评论
]]>Summary
Reggie illuminates the underlying performance impact of using the StringBuffer and String classes when performing concatenations. (600 words)
By Reggie Hutcherson
Java provides the StringBuffer and String classes, and the String class is used to manipulate character strings that cannot be changed. Simply stated, objects of type String are read only and immutable. The StringBuffer class is used to represent characters that can be modified.
The significant performance difference between these two classes is that StringBuffer is faster than String when performing simple concatenations. In String manipulation code, character strings are routinely concatenated. Using the String class, concatenations are typically performed as follows:
String str = new String ("Stanford ");
str += "Lost!!";
If you were to use StringBuffer to perform the same concatenation, you would need code that looks like this:
StringBuffer str = new StringBuffer ("Stanford ");
str.append("Lost!!");
Developers usually assume that the first example above is more efficient because they think that the second example, which uses the append method for concatenation, is more costly than the first example, which uses the + operator to concatenate two String objects.
The + operator appears innocent, but the code generated produces some surprises. Using a StringBuffer for concatenation can in fact produce code that is significantly faster than using a String. To discover why this is the case, we must examine the generated bytecode from our two examples. The bytecode for the example using String looks like this:
0 new #7
3 dup
4 ldc #2
6 invokespecial #12
9 astore_1
10 new #8
13 dup
14 aload_1
15 invokestatic #23
18 invokespecial #13
21 ldc #1
23 invokevirtual #15
26 invokevirtual #22
29 astore_1
The bytecode at locations 0 through 9 is executed for the first line of code, namely:
String str = new String("Stanford ");
Then, the bytecode at location 10 through 29 is executed for the concatenation:
str += "Lost!!";
Things get interesting here. The bytecode generated for the concatenation creates a StringBuffer object, then invokes its append method: the temporary StringBuffer object is created at location 10, and its append method is called at location 23. Because the String class is immutable, a StringBuffer must be used for concatenation.
After the concatenation is performed on the StringBuffer object, it must be converted back into a String. This is done with the call to the toString method at location 26. This method creates a new String object from the temporary StringBuffer object. The creation of this temporary StringBuffer object and its subsequent conversion back into a String object are very expensive.
In summary, the two lines of code above result in the creation of three objects:
A String object at location 0
A StringBuffer object at location 10
A String object at location 26
Now, let's look at the bytecode generated for the example using StringBuffer:
0 new #8
3 dup
4 ldc #2
6 invokespecial #13
9 astore_1
10 aload_1
11 ldc #1
13 invokevirtual #15
16 pop
The bytecode at locations 0 to 9 is executed for the first line of code:
StringBuffer str = new StringBuffer("Stanford ");
The bytecode at location 10 to 16 is then executed for the concatenation:
str.append("Lost!!");
Notice that, as is the case in the first example, this code invokes the append method of a StringBuffer object. Unlike the first example, however, there is no need to create a temporary StringBuffer and then convert it into a String object. This code creates only one object, the StringBuffer, at location 0.
In conclusion, StringBuffer concatenation is significantly faster than String concatenation. Obviously, StringBuffers should be used in this type of operation when possible. If the functionality of the String class is desired, consider using a StringBuffer for concatenation and then performing one conversion to String.
About the author
Reggie Hutcherson is a Sun technology evangelist. He evangelizes Sun's Java 2 Platform technologies around the world concentrating on J2SE and the HotSpot performance engine.
Resources
"JavaWorld debuts new weekly Java performance column," Reggie Hutcherson (JavaWorld, March 2000):
http://www.javaworld.com/jw-03-2000/jw-03-javaperf.html
"The basics of Java performance," Reggie Hutcherson (JavaWorld, March 2000):
http://www.javaworld.com/jw-03-2000/jw-03-javaperf_2.html
"Performance problem or design problem?" Reggie Hutcherson (JavaWorld, March 2000):
http://www.javaworld.com/jw-03-2000/jw-03-javaperf_3.html
"Compiler optimizations," Reggie Hutcherson (JavaWorld, March 2000):
http://www.javaworld.com/jw-03-2000/jw-03-javaperf_4.html
javaGrowing 2005-09-12 09:25 发表评论
]]>01/29/2004
javaGrowing 2005-09-12 09:24 发表评论
]]>