commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Rosenberg <>
Subject Re: Is DiskFileItemFactory Thread Safe?
Date Sun, 07 Feb 2010 16:39:50 GMT
On Sun, Feb 7, 2010 at 3:39 PM, James Mansion
<> wrote:
> Andrew Thorburn wrote:
>> Indeed. It's generally regarded as an anti-pattern.
>> evebill8: See below for a couple of links talking about it if your
>> co-workers grumble about it (and for anyone else who comes along
>> asking these questions, I guess).
> Personally, I regard people trotting out 'premature optimisation is the
> root' as an
> anti-pattern too. It is emphatically NOT possible to achieve high
> performance by
> relying on the profiler to tell you what's wrong.  Its certainly a big help
> and can
> point you at code to look at, but really you need to consider performance
> right
> through from the design phase onwards. You can use a profiler to drive out
> hot
> spots but you'll still be limited by the design's constraints, particularly
> where
> you have distributed components or hardware IO and you're killed by latency,
> or by inter-thread sync issues, rather than CPU intensive blocks.
> Personally I would encourage consideration through design review, and code
> review.  Its cheaper to catch it early than to debug and have to refactor
> and
> redisgn. I'm NOT advocating tuning every last operation, just that
> discussion
> and consideration IS healthy and is NOT an anti-pattern.

The discussion depends highly on the education and experience level of
the persons involved.
Persons who have walked in the field and are experienced in the high
performance area will not due common performance errors even without
premature optimization. For example everyone in the high traffic B2C
portal environment knows that JOINs are bad for performance and
doesn't use them.
However, generally people who are doing premature optimization have
neither experience nor knowledge. For them the advise: premature
optimization is the root of all evil applies.
However, the best way to achieve performance is to write clear code
that acts straight forward. If the real usage of your application
leads to zero lock contention (which is unlikely but can happen), than
you will have no "inter-thread sync issues" and trying to prematurely
resolve them by complicated, not easy understandable code, is not only
waste of resources, but also makes the code harder to maintain in the

just another 2 cents :-)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message