On Mar 24, 2017, at 4:11 PM, Simon Barber <simon.barber@xxxxxxxxxx> wrote:
> When loading a large file (0.5M packets) with a large single TCP stream in it, wireshark gets very slow. I did some profiling and found 90% of the CPU time was spent in epan/reassemble.c LINK_FRAG() - scanning through a long singly linked list and adding to the end of it.
So is the stream one, or a small number of, huge packets when reassembled? If a packet has stuff from two TCP segments, that shouldn't be slow.
A quick 99% optimization would be to save a pointer to the end of the list and, if the new fragment should go after the last item in the list, just add it there.
In the general case, perhaps a tree would work better, as the goal of LINK_FRAG() is to find the appropriate place to insert the new fragment so that the set of fragments is sorted by fragment offset.
