[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Duplicate object prevention policy

From: Stephen Crawley
Subject: Re: Duplicate object prevention policy
Date: Thu, 01 Dec 2005 16:43:49 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319

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
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]