On Thu, Jan 25, 2001 at 05:44:06AM -0700, Warren Young wrote:
> If you use a balanced tree or a hash table, lookup time would be
> minimal.
And, at least right now, the bulk of the CPU time spend doing the
initial pass through a capture file is spend doing stuff such as copying
strings around, allocating memory for strings, and formatting strings;
in my (still very much under development) version with a "virtual" CList
widget, so that the widget that implements the packet list pane doesn't
have to chew up tons of memory allocating copies of the strings in every
single column of every single row, and doesn't have to chew up CPU doing
the copying, it's dominated by "vfprintf()" (i.e., generating columns
such as the Info column) and "memcpy()" (also called, mainly, as a
result of calling "snprintf()" and company when formatting those
columns).
Making Ethereal checksum all TCP segments not part of fragmented IP
datagrams, and all UDP datagrams that have checksums and that aren't
in a fragmented IP datagram, made no noticeable difference in the CPU
time it took to read the capture in.
> For a balanced tree with 100,000 elements (the number of files
> in a typical desktop computer's filesystem), the tree will only be 17
> levels deep. These days, with STL available for virtually every
> compiler,
Even C compilers? :-)
As noted by Jeff Foster, GLib also has a balanced tree implementation:
http://developer.gnome.org/doc/API/glib/glib-balanced-binary-trees.html
so if the dissector is written in C, you still don't have to roll your
own.
