The current widget used for displaying the packet summary requires that the text for every row be generated when the row is added to the display, regardless of whether the row happens to be displayed or not.
This means that, in order for it to even be *possible* to see the summary line for a packet by scrolling that widget, the packet has to be dissected.
I assumed that was the case, or else it wouldn't behave that way now.
At some point we might have a widget that will dissect the packet "on the fly" in order to generate the column text. However:
That's what I figured would have to be done. Looking at the small bits of performance gain you guys are getting here and there, I'm guessing that all the easy tweaks have been done.
1) Ethereal will still have to, before dissecting a packet for the first time, dissect all packets before it, as Ethereal dissection is stateful (if it weren't stateful, many packets it can currently dissect wouldn't be dissectable, as the correct dissection of those packets depends on information obtained by dissecting earlier packets);
How about being able to go back far enough to dissect the current row? I.e. dissect it, decide that it belongs to the middle of a TCP connection, go back until you get all the packets that belong to that connection (to the SYN) and go forward from there. Won't work for UDP, I suppose.
2) Ethereal will still have to read in those packets so that it knows how many packets there are, so it (or, rather, the widget it uses to display the packet summaries) can make the scrollbar work to show you those packets.
Surely a counter could be kept. Unless I'm misunderstanding what you're saying.
Currently, display filters require a full dissection. It might be possible to change the display filter code to cut dissection short as soon as a filter matches, but
1) that wouldn't help for the initial dissection of a packet, as that has to be sufficient to generate enough state for subsequent packets (and, for any dissector that calls other dissectors, that means dissecting enough to call those other dissectors);
2) that wouldn't help for packets that *don't* match the display filter, unless the display filter code can somehow know that subsequent protocols won't make a difference (which requires that it know for certain what other protocols will, and won't, be seen when dissecting), and that won't help in all cases;
3) that would probably not be a trivial change to the display filter code.
I don't know enough about how the filters work to comment. I also don't mean to imply that any of the changes would be trivial. I'm used to mostly simple filters, so I'm sure I don't appreciate all the problems involved. I appreciate you taking the time to explain some of the issues to me.
BB
