On Mar 24, 2017, at 4:11 PM, Simon Barber <[email protected]> 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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
