Comments on: Optimizing Java Code http://www.symphonious.net/2004/02/01/optimizing-java-code/ Living in a state of accord. Tue, 06 Jan 2009 10:44:34 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Rick Jelliffe http://www.symphonious.net/2004/02/01/optimizing-java-code/comment-page-1/#comment-444 Rick Jelliffe Wed, 09 Mar 2005 06:06:52 +0000 http://localhost/wordpress/?p=12#comment-444 The desktop applications my company makes are editors: these have to be treated pretty much like real-time systems. From the users' perspective, any interruption during typing makes the application unpleasant or unusable. So we have a primary requirement that lengthy major GC must be avoided during user typing, which is most of the time (i.e. no "time off"): such a pause must indeed be treated like a failure to be defended against. My blog doesn't mention optimising for speed once, by the way. Your point about NullPointerException is a good one: at Topologi we address it by using the excellent jlint as part of our development process to warn the developer if this has happened. Though surely the programmer would typically test the code and discover the null? And if the program was written defensively any methods called would also check their arguments for null too? Your point on increasing the young generation is good also: but there is a tradeoff that it can be desirable to tenure large objects directly into the old generation (less copying, more objects kept in young generation). Enlarging Eden will help GC in some cases, freeing up references to help the minor collector will be good in some others: they are neither mutually exclusive nor substitutable. Can I approach this from another angle: what if you periodically profiled your application, and you regularly found that out-of-memory errors and major GCs could be avoided by paying good attention to explicit nulling (inter alia)--are you saying that no lesson about best practises should be learned? In a relatively simple application, we can expect to get pretty good coverage from a profiling tool: when the application is complex, with many different user scenarios, profiling is inadequate: it is the process improvement that becomes important--learning prudent practises as a result of profiling. And that is what my blog was about: we improved our memory problems by paying attention to object reachability, contrary to the bland generic advice the WWW is awash with. The desktop applications my company makes are editors: these have to be treated pretty much like real-time systems. From the users’ perspective, any interruption during typing makes the application unpleasant or unusable. So we have a primary requirement that lengthy major GC must be avoided during user typing, which is most of the time (i.e. no “time off”): such a pause must indeed be treated like a failure to be defended against. My blog doesn’t mention optimising for speed once, by the way.

Your point about NullPointerException is a good one: at Topologi we address it by using the excellent jlint as part of our development process to warn the developer if this has happened. Though surely the programmer would typically test the code and discover the null? And if the program was written defensively any methods called would also check their arguments for null too?

Your point on increasing the young generation is good also: but there is a tradeoff that it can be desirable to tenure large objects directly into the old generation (less copying, more objects kept in young generation). Enlarging Eden will help GC in some cases, freeing up references to help the minor collector will be good in some others: they are neither mutually exclusive nor substitutable.

Can I approach this from another angle: what if you periodically profiled your application, and you regularly found that out-of-memory errors and major GCs could be avoided by paying good attention to
explicit nulling (inter alia)–are you saying that no lesson about best practises should be learned?
In a relatively simple application, we can expect to get pretty good coverage from a profiling tool:
when the application is complex, with many different user scenarios, profiling is inadequate: it is the
process improvement that becomes important–learning prudent practises as a result of profiling. And that is what my blog was about: we improved our memory problems by paying attention to object reachability, contrary to the bland generic advice the WWW is awash with.

]]>