commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <Matthew.H...@capitalone.com>
Subject RE: [lang] Reusable Builder classes
Date Thu, 02 Oct 2003 11:16:11 GMT
Modern generational collection is superb but still can't be beaten by just
not creating the object in the first place (though bad pooling can make
things worse not better)

If you use CompareToBuilder and EqualsBuilder on the same object set
optimization to use CompareTo == 0 rather than a separate EqualsBuilder may
provide some improvements if this contract is maintained (which it really
should be)

This could avoid EqualsBuilder use if this would be as a result of a chain
of comparisons.

To be honest though the builders provide a way to do a set of tasks with
minimal coding and maintenance overhead... This will very likely conflict
with your requirements of 'need for speed' it is rare and lovley code that
achieves both perfectly.

Profiling your app to find out which Object comparisons/equality checks
happen the most/take the longest and putting in hand tuned code there will
likely do more for you...

Especially if you have a lot of String comparisons, tuning the order of
these comparisons (and doing things like assuming the most likely case will
be that the case is identical even if you must then check if its not)

Matt

-----Original Message-----
From: Don Forbes [mailto:Don.Forbes@2cana.co.za] 
Sent: 02 October 2003 10:32
To: commons-user@jakarta.apache.org
Subject: RE: [lang] Reusable Builder classes



Sorry, I took it as a given that excessive object creation was an evil, e.g.
Brian Goetz's JavaWorld article "Design for Performance, Part 2: Reduce
Object Creation"
(http://developer.java.sun.com/developer/technicalArticles/Programming/class
performance/); see also e.g.
http://www.oreilly.com/catalog/javapt/chapter/ch04.html,
http://www.javaworld.com/javaworld/jw-11-1999/jw-11-performance.html.

I do quite a lot of performance-critical work involving large collections of
objects.  For instance, transforming mainframe extracts of several million
records into data warehouse load files.  This may entail using several
lookup caches in the form of SortedMaps, HashMaps or sorted arrays (with
binary search) which may themselves contain millions of entries.  We aim for
the complete cache load and transformation to run in minutes rather than
hours.

This environment multiplies the effect of bad choices and the effects on run
times visibly punishes things like avoidable object creation.  This is not
about milliseconds.

Matt's suggestion makes sense for HashCodeBuilder, it had crossed my mind
too.  But it won't work for CompareToBuilder or EqualsBuilder.  I felt my
suggestion was a good compromise with a consistent approach to all the
Builder classes.  I'm familiar with the debate about premature optimisation
but I don't feel that label is really called for here.

I'm not sure that doing an analysis that would satisfy the purists is
something I can afford to do now.  I understand that my requirement is
perhaps rather specialised, and at least now I know where I stand.

When time permits I'll benchmark some options and also count the number of
times compareTo() gets invoked doing sorts etc., and let you know.

Thanks for your interest.

Don
  

-----Original Message-----
From: Hope, Matthew [mailto:Matthew.Hope@capitalone.com]
Sent: 01 October 2003 11:56
To: 'Jakarta Commons Users List'
Subject: RE: [lang] Reusable Builder classes


The end user may wish to consider whether their use case would benefit from
caching the calculated value...

If you can handle doing the coding of a dirty flag and its maintenance then
the only overhead is in a boolean, int (and possibly String if you want to
cache toString()) instance variable.

If the data rarely changes and the performance in this area is really what
matters this will provide far more bang for buck than just caching the
Builder Object.

But what everyone else said is the place to start - is this really what's
killing performance, what does profiling tell you?

Matt

-----Original Message-----
From: __matthewHawthorne [mailto:matth@phreaker.net] 
Sent: 30 September 2003 23:25
To: Jakarta Commons Users List
Subject: Re: [lang] Reusable Builder classes


Another quote I've heard: "premature optimization is the root of all 
evil."  I agree with what you're saying.

With the exception of some common sense situations, I think that 
performance optimizations carry the ability to pollute an API and mangle 
the internal code.  Garbage collection is improving, JVMs are getting 
faster... I'd prefer clean, maintainable code over that which goes to 
extremes to save a few milliseconds.

Measurements are a necessity for this sort of thing.  I think the 
problem has to be proven before the solution is started.  There's a nice 
profiler plugin for Eclipse that I've used a few times, it seems to do 
the job.




Gary Gregory wrote:

> Hi,
> 
> I am always very weary of doing anything in the name of performance
> without any measurements based on a real usage scenario. Old motto on 
> performance
> improvements: First, don't' do it. Second, think about it, then don't do
it.
> ;-)
> 
> I think it would be interesting to discuss this if/when the post read
> like: "In our app x, we've measured with JProbe (or whatever) a 
> bottleneck in this and that place were 80% of the time for a set of 
> tasks is spent in FooBuilder.doThisOrThat()."
> 
> There are two kinds of performance: speed and memory usage. Here we
> are talking about creating code to change the profile and balance of 
> these two aspects based on a hunch. I have been to many performance 
> talks (JavaOne) where one hears things like (paraphrasing): "in an 
> extreme case, we had this customer try such and such performance 
> improvements of caching this and that in memory which effectively 
> negated GC from collecting anything and led to a different kind of 
> memory leak (a.k.a unwanted object retention) and performance 
> degradation due to virtual memory swapping".
> 
> From the POV of client code, this seems like quite a complication to
> deal with, especially when considering MT issues.
> 
> Without talking sides on the details of this particular issue, when
> designing an API, you also have to consider what choices you'll give 
> client code. At which point will the client code writer scratch his 
> head with a "there are so many ways of doing the same thing, which one 
> is best and when?". It is best if all of these choices are documented.
> 
> Gary
> 
> 
>>-----Original Message-----
>>From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>>Sent: Tuesday, September 30, 2003 13:03
>>To: Jakarta Commons Users List
>>Subject: Re: [lang] Reusable Builder classes
>>
>>Possible I suppose. I guess I don't have strong views either for or
>>against.
>>
>>Any other [lang] committers have any views?
>>
>>Stephen
>>
>>----- Original Message -----
>>From: "Don Forbes" <Don.Forbes@2cana.co.za>
>>I find the Builder classes really helpful, but find it wasteful having
>>to create a new HashCodeBuilder, CompareToBuilder or EqualsBuilder for 
>>each invocation of a hashCode, equals or compareTo method.  In some 
>>situations, such as a sort of a large collection, these methods can 
>>end up being called often, thus imposing a high garbage collection 
>>overhead.
>>
>>I am thinking of something analogous to StringBuffer, which can be
>>reset for reuse by simply calling setLength(0).
>>
>>How about a simple reset() method, with no parameters, that just
>>resets the internal state (e.g. the variable "comparison" in the case 
>>of
>>CompareToBuilder) to its initial value?  (Possibly also a getter to 
>>determine whether the builder is currently in a reusable state.)
>>
>>Granted, this would require the Builder to be an instance variable of
>>the calling object rather than a local variable, thus raising issues 
>>of thread safety.  Unfortunately using sychronized methods has 
>>something of a bad name for performance.  In my understanding and 
>>experience this is an unfair reputation, and my guess is that the 
>>overhead would be amply compensated for
>>by the savings in garbage collection.  But short of this, provided the
>>caller is given the responsibility for synchronising access to the object
>>in
>>a multithreading scenario, I don't see a problem.
>>
>>Any thoughts?
>>
>>
>>Don
>>
>>---
>>Outgoing mail is certified Virus Free.
>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>Version: 6.0.515 / Virus Database: 313 - Release Date: 2003/09/01
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003/09/01
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003/09/01
 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message