commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] Reusable Builder classes
Date Tue, 30 Sep 2003 21:54:04 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message