Remove from Hashtable? [easy one]

  • Thread starter Thread starter Jules Winfield
  • Start date Start date
J

Jules Winfield

I'm often in a situation where I have a Hashtable full of objects. I'm
then presented with an object and *if* that object exists in the Hashtable,
I need to remove it from the table. I therefore have a lot of code that
looks like this:

if(ht.Contains(obj)){
ht.Remove(obj);
}

It strikes me that this code is somewhat inefficient because the
Hasthtable has to be searched *twice* : once for the Contains() call and
once for the Remove() call. So I thought maybe I should approach the
situation this way:

try{
ht.Remove(obj);
}
catch(Exception){}

Now I'm only searching the Hashtable once... but is the overhead of
throwing the exception cancelling out any benefit that I achieved by not
calling Contains()? To answer this question, you probably need to know how
frequently 'obj' is actually found in the Hashtable. For the sake of
argument, let's say 50%.

Thanks,

Jules
 
Jules,

You can find this out easily. Why not run a few tests and time it?

If I had to guess, I would say that the overhead of determining if an
object exists in a hashtable is less than the overhead of catching the
exception.

Also, from a maintainability standpoint, it makes more sense, as you are
using exceptions to for programming logic, when a suitable construct is
already there.

Hope this helps.
 
Jules Winfield said:
I'm often in a situation where I have a Hashtable full of objects. I'm
then presented with an object and *if* that object exists in the
Hashtable, I need to remove it from the table. I therefore have a lot of
code that looks like this:

if(ht.Contains(obj)){
ht.Remove(obj);
}

It strikes me that this code is somewhat inefficient because the
Hasthtable has to be searched *twice* : once for the Contains() call and
once for the Remove() call. So I thought maybe I should approach the
situation this way:

try{
ht.Remove(obj);
}
catch(Exception){}

Now I'm only searching the Hashtable once... but is the overhead of
throwing the exception cancelling out any benefit that I achieved by not
calling Contains()? To answer this question, you probably need to know how
frequently 'obj' is actually found in the Hashtable. For the sake of
argument, let's say 50%.

Thanks,

Jules
Click to expand...

Also, you should not worry (too much) about performance when programming. It
is good practice to make the program, test it, and then deal with any
potential performance issues.

This is also due to the fact that the bottle necks usually are not in the
places you expect them to be, unless, of course, you are an experienced
programmer and you *know* this will be a bottle neck.

Experienced programmers call this premature optimizations.

Wait and see if searching the hash table twice takes a significant
percentage of your program's cpu time when the program is done, *then* deal
with it! :o)

The best,
Mogens
 
I second Mogens' advice.

While it is annoying to have to search the Hashtable twice, once to
check and once to remove the item, I think that this way of writing the
code will be easier to understand for other programmers. Besides, the
object not being in the Hashtable isn't really "exceptional," is it?
It's something you expect to happen regularly, so using an exception
seems a hack to me.

Trust us. :-) You gain far more speed by thinking hard about whether a
Hashtable is the right thing to use in a given situation than you do by
making little code tweaks like this one. Once you have a working
program, run it through a profiler and see where the speed problems
lie, and fix them where you find them.
 
Thanks for the tips, guys. I won't concern myself with trivial
optimizations like this unless I see that there's a performance bottleneck.

Jules
 
Jules-

i am confused at what you're doing here.

According to everything in my experience (including reading reading the
docs), Hashtable.Remove only throws an exception if the argument is null, the
table is read-only, or the table has a fixed size.

A Simple Element-Not-Found does NOT throw an exception.

Just Remove away!

now... if you were trying to properly catch all exceptions, then you should
have also looked for ArgumentNullException as well as NotSupportedException,
but that's immaterial to the examples you've presented.

No performance penalty at all =)
 
A Simple Element-Not-Found does NOT throw an exception.

Ha! You're right!

I've been calling Contains() before removing since the tech preview of the
original .NET back in like 2000 or 2001 or so. I've been doing it because I
read in a tutorial that you were supposed to do this. Either the tutorial
was completely wrong or the beta version of .NET that I was using back then
actually did throw an exception when Remove() was called with an keythat
doesn't exist in the Hashtable. It's funny how a bad habit learned back in
2001 stuck with me all of these years.

Despite the moot point re:Remove(), a similar issue caught my attention
recently with the IDictionary<T> Item (that is, [] indexer) property. It
throws an exception when the key isn't found, unlike it's non-generic
counterpart which simply returns null. It looks like Microsoft addressed the
issue with a new method called TryGetValue(), which acts a lot like the []
indexer but won't throw an exception when the key isn't found.

Jules
 
Back
Top