https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6755
--- Comment #8 from Cristian Constantin <const.crist@xxxxxxxxxxxxxx> 2012-01-27 00:58:17 PST ---
(In reply to comment #6)
> The title might be a bit misleading - if you have 5 million frames all of which
> belong to the *same* TCP connection, the code in question probably isn't going
> to make a bit of difference. If you have 500k frames that belong to 50k
> conversations, it might make a lot of difference. I.e., the problem isn't that
> there are a lot of *frames*, the problem is that there are a lot of
> *conversations* (which would require a lot of frames, but the problem isn't
> just that there are a lot of frames).
>
> So Cristian's trace might not just be twice as big as Anders' trace, it might
> have a lot more TCP connections than Anders' trace.
cristian: hi!
first of all I did performance/stress test of this using sip/udp.
and it is actually happening (at least for udp) the other way around:
when you are having _one_ udp conversation with 100s of Ks of frames, wireshark
is really slow loading/processing them. why? because all the frames having
the same (hashtable) key (ip:port, protocol) will be stored in a linear list
being _appended_ (randomly, as they come); the slow down appears when they are
looked up in the linear list.
in the bug description, by "large conversations" I mean a conversation (in my
case udp) which is having over 300k frames.
bye now!
cristian
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.