A nice article over a IBM's DeveloperWorks: Java theory and practice: Garbage collection and performance
Tapestry went through this same kind of work over back in the 2.0 timeframe (around the time of JDK 1.3). I went to a lot of trouble to pool all sorts of little objects, particularily StringBuffers. Guess what? Performance went down! I knew this because I did some profiling. I stripped all the pooling code out and, even with all those short term instantiations of StringBuffers and the like, performance went back up. Later JDKs have helped even more.
There are too many moving parts in a Java application (too many frameworks, too many layers of too many different kinds of code, too many threads) to predict how performance will be affected by your code changes. As the IBM article points out ... you can easily hurt more than you help.
No comments:
Post a Comment
Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.
Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者：不要打扰。我删除您的评论和它的时间对我们双方的浪费