Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 17485: /trunk/epan/: emem.c emem.h

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: Tue, 7 Mar 2006 04:47:00 +0100
On 3/7/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> Do we really want hashtables ?
They may turn useful...

How do we handle arbitrary length strings with the rb_tree?

> Hashtables very quickly degenerate to becoming a very slow linear search.
> Usually they do not provide any savings in memory usage either
Ack

> So their only benefit is that they are so conceptually simple that one can
> hack them up from memory in 5 minutes.

There are several hashtables with string indices in the codebase so I
thought them as a replacement until we figure out a mechanism to
handle arbitrary length strings.

We should keep the interface... I won't argue on the fact that there
are better implementations.

> I belive binary trees are superior in every single respect (now that we
> already have them and implementation is not an issue)
> * they are as memory efficient as hash tables
> * they are infinitely faster than hashtables.

Still the issue: how do we handle arbitrary length string keys?

> Do you really really want to have hashtables here?
> I think we should not implement hashtables.

We could make the keys limited to at most 128 bytes and handle them as
an array of (up to?) 32 32bit integers...

L

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan