On Sep 26, 2006, at 10:02 AM, Brian Vandenberg wrote:
... then doing dissection on new_data. Everything seemed fine
until I
started dissecting packets with large amounts of raw data (100k+).
The
more raw data I have, the worse performance gets (go figure).
The more raw data you have, the more lines of text are added to the
hex/ASCII display pane, and GTK+'s text widget isn't exactly
screamingly fast.
Ideally, we'd have our own widget for that, which would, when a line
is to be displayed, call back to a routine which could fetch the
values on the line from the raw data and format the line at that
point, rather than requiring every single line that *could* be
displayed to be generated and appended to the text widget.
When
there's a large enough amount of data to dissect I get a window that
says "Processing packet details", with status information such as the
number of bytes processed, etc.
That's from packet_hex_print_common(), which is constructing the text
for the hex/ASCII display pane. It's using
delayed_create_progress_dlg(), so that the progress window doesn't pop
up unless the task has taken "enough" time.
The comment at the beginning of packet_hex_print_common() mentions
that we might want a custom widget for this, perhaps one that
generates the displayable text on the fly.
So, I guess what I'm wondering is, is this expected behavior when
trying to crunch this much data?
Unfortunately, while it's not desired, it's expected.
I'm only adding a few things to the
tree right now, namely an FT_UINT8 (with an associated value_string
array), an FT_UINT16 (displayed using BASE_DEC_HEX), and FT_BYTES; the
latter may require a large number of bytes to be selected (this
particular payload type could have 500k or more that gets
highlighted in
the tree view).
The "Packet Details" in the progress dialog is a bit misleading - it's
not constructing the packet details pane, it's constructing the hex/
ASCII dump pane, so it doesn't matter how much stuff you're adding to
the tree, it's just a function of how much raw data there is.