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. _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
