On Fri, 2007-10-26 at 11:46 -0700, Tatu Saloranta wrote: > > 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 +- >
Hi Tatu I agree wholeheartedly. Moreover, I personally think changes that yield only marginal performance improvements (less than 5%) at the expense of code clarity are counter-productive, especially for rapidly evolving code lines. Cheers Oleg > > > > __________________________________________________ > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
