Re: Duplicate object prevention policy

[Stephen Crawley]

Jan Röhrich wrote:

> > The theoretical answer depends on lots of things, such as:
> >
> >  1) the probable number of times that the method will be called, 
> >  2) the likelihood that the lookup (if implemented) will succeed,
> >  3) the cost of creating the object,
> >  4) the cost of the name lookup is,
> >  5) the incremental GC cost if duplicate copies of the object become
> >     garbage,
> >  6) the incremental GC cost if the mapping data structure keeps 
> >     otherwise garbage objects alive, 
> >  7) the incremental GC cost if the application keeps duplicate
> >     copies of the objects alive,
> >  8) the (speculative) cost of using obj.equals(obj2) versus obj == obj2
> >     if we could guarantee that objects are ONLY created via the method,
> >  9) etcetera
> >     
> >
> > And all of these depend on the nature of the objects and the way that they
> > are used in a typical application.  In short, there are no general answers.
> >    
>
> Hi Steve,
>
> I know that this depends on a lot of things but I just wanted to know if
> this has been discussed before and if there is any "guide" for the most
> likely cases.
>
>  
I don't recollect any previous discussion ...

But I don't think it makes sense to discuss this in the general sense, 
simply because
the answer for the "most likely case" (what ever that might be) doesn't 
help you in
particular cases.  One could infer some "rules of thumb" like the following:

   *  if that lookup is not likely to succeed, don't use mapping
   *  if the method is seldom called, there is little point in a mapping
   *  if the objects in the mapping are transitory, use a WeakHashMap
   *  etc

... but the problem is that there are always counter-examples. 

So my best advice would be to think through the issues for each and 
every situation,
giving careful consideration to the likely application usage patterns. 

But don't worry too much.  If you make a marginally bad choice it 
probably won't
matter for most applications anyway.   Usually, nobody cares much if an 
application
runs (say) 10% slower than it needs to.  In most cases, they don't even 
notice the 10%!

If it turns out that the mapping / no mapping decision does matter, it 
will eventually
show up in application profiling.  This will allow you (or the future 
maintainer) to
make an informed decision about what to do.  [And that might simply be 
to update
the javadoc to say "if you do xyz, your application will be slow".]

My philosophy is to avoid premature optimization.

-- Steve