> Besides, you may want to use some sort of benchmark to quantify > differences in performance before and after changes. I did a lot of > optimization on HttpCore (the low level set of components HttpClient 4.0 > is based on) a while ago but I was using JProfiler to find critical > performance bottlenecks.
I would go even further, and claim that any change that is made solely to improve performance (and this does not include cases where code readability etc is improved), and that has NOT been tested to show some positive effect, is potentially a useless change. Fortunately one does not always have to show end-to-end benefit: a micro-benchmark for isolated use case can work well enough to show the effect. From that one still should be able to argue that this result has transitive effect, being a common (enough) use case. Or put another way: performance of code run only once or twice usually doesn't matter at all. The reason why such testing should almost be mandatory is because: * Yes, HotSpot optimizes many common and seeminly wasteful patterns very well; meaning it can already optimize lots of things out * Garbage collection of short-lived temporary objects is VERY fast nowadays, meaning that reduction in garbage (at scale of, say, couple per http request) is very unlikely to have any positive impact. This means, for example, that cost of using Iterators over indexing (when accessing Lists, Maps) is negligible and usually irrelevant wrt. performance. * GC overhead for _long-lived_ objects is, relatively speaking, expensive, making many object pool use cases counter-productive. * Synchronization is, at method-level, very very cheap. Its only significant expense comes if there are actual multiple threads with lock contention. Uncontested syncing is fast enough to be hard to even measure, when we talk about multi-millisecond costs of i/o operations. * Lazy initialization can be useful, but can also complicate code; and sometimes cause concurrency problems. Eager initialization is simpler and allows making fields immutable (when passed-in/constructed by constructor), and perhaps making the whole object immutable and hence reusable without locking. * Profilers are useful as tools, but _only when coupled with detailed knowledge of code itself_. Often i/o wait times are included for code that blocks, even though it doesn't use any cpu. There are often artifacts, due to profiling environment running a bit different from real system. This can seriously skew timings too, if JVM isn't allowed to optimize parts it otherwise would. As such, I agree in that random patching of things is most useful as a learning exercise. Of proposed changes, I think that changes from Iterators to indexed access, and trying to remove some of synchornized keywords is very unlikely to lead to any performance improvements. Deferring construction of Maps may be useful, as long as they remove the need to construct instances at all for significant number of use cases. If they eventually always get constructed, there's no point. -+ Tatu +- __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
