Spring性能小测，参其它技术

无意义的讨论很容易误导其它人的，既然robbin指出你的测试方式有问题，测试出来的数据没有任何意义。那为什么不询问下有意义的测试方式，最后得到一些有意义的数据呢。我遇到的企业项目的开发中，最后出性能问题基本上都是设计上的失误，很少有因为语言性能导致的。

企业应用一般不会遇到什么性能问题，一旦遇到就硬伤，比如，用户要求一次导出20w行数据到Excel，过程中还需要各种计算，涉及多个tables。我们说，导出这么多数据没用呀，又不是看金庸的小说。可是用户不管你，让你导你就导，不导也得导。结果呢，性能很差，大约要用十几分钟，而且有时候还内存溢出。
这种时候，用什么语言都一样，所以我基本同意robbin的观点的。

hibernate没问题
有问题的是用hibernate的人

小声地问一下,你不分开几个文件导出么?20w分10次,导到temp中10个文件,然后合并输出不可以?

之前听说过google用Tapestry，不过找不到明确证据，要说google用java做web的侧面证据是GWT是java的。

我觉得这个贴子应该成为精华贴，
如果将这类问题老是搞得看不见的话，就会有人不断提这种问题。
编辑们多努力阿。

题外话说完了，说和性能相关的问题。
其实最能改善软件性能的是大脑的性能，robbin已经说得如此明白，但是有的同学仍然固执到坚强的地步，不知道是不明白，还是放不下。
大的架构方面的robbin已经说了。我从中学到不少。
既然说语言，那就说说语言，不管是C++，Java，ruby，写得好不好对性能的影响远远超过了语言本身。
以前曾经有几个Oracle存储过程，用来计算一些报表数据。计算一次需要20小时左右。
一再给客户解释，存储过程性能问题，要解决要用C语言重写。我最讨厌的就是将时间花在为自己无能的辩解上，而不是花在解决问题上。结果，我将存储过程改写后，四个小时就可以计算完成。发现任何错误重新计算正确的时间在5分钟以内。

不要解决假想的问题，不要把时间浪费在讨论哪门语言上，碰到问题是个好机会，解决它。不要怀疑你所用的语言，多怀疑自己。
做一个小程序来测试性能是很搞笑的事情。
经常见到不到100万条数据就在那里叫数据好多。
搞个连玩具都算不上的东东在那里比较性能。
真的，比较性能这种事，你目前还没有必要做。要做的事，尽可能提高现有系统的性能。重构代码，优化服务器。

上面有位同学说导出20W条数据够呛，其实十几分钟不算长，如果一个月导一次，有什么关系？但内存溢出问题不得不解决。
如果一天导个几次，或者有一万个人要导，而不仅仅是办公室主任一个人要，就是大问题了。任何问题离开了实际的场景没有任何意义。
导这20W数据还有机器配置的问题。
做一件事情，最重要的是方法问题。
让我猜一下这个问题吧。
首先要确认是计算花时间，还是写Excel花时间。
是否可以建临时表，临时文件
是否可以使用多线程
只要把问题搞清楚了，就好解决。
我做过，处理上千万数据生成N个报表，也不需要这么长时间。用的是C++。
但我相信不是语言的问题。
现在一般的PC都比那时好，所以应该更快。

作为程序员，请不要写令人发指的程序来冤枉编程语言。

第一点有问题：jdbc不带cache。

可以自己加cache，也不是什么麻烦事。

是啊，不麻烦，jdbc+自己的cache再加上通过反射读取原数据定义（或者xml定义），动态生成sql，就是hibernate了。

我就是把Hibernate当成sql生成器起来用的，从来不把它当什么面向对象数据接口，绝对比什么iBatis方便，特殊需求除外（创建表等）。

还有就是Hibernate对原生sql的支持度是很强的，很多人刚入门的不知道而已，只知道个iBatis。

使用iBatis，一旦碰到sql是要根据一些复杂业务的条件拼出来的就知道痛苦了，大量的工作量在写配置文件和配置脚本，IDE对配置文件支持度是远不如代码的。

java有个缺点就是对象的回收速度上比不上C++
一般的计算不花时间,尤其表不是巨大的时候,20w的数据显得不是特别大,excel的cell创建和style渲染会耗费大量的cpu,否则分页输出web格式的报表还是没有太大的问题的,不像excel输出如此变态.