https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7149
--- Comment #13 from Cristian Constantin <const.crist@xxxxxxxxxxxxxx> 2012-04-19 12:40:51 PDT ---
(In reply to comment #10)
> It's really O(n log n) you forgot about hash tree :-)
>
> But if it's *really* so expensive (from 20min down to 6seconds),
> maybe it'd be better to generate/find conversation once, and store it in packet
> structure. mhm.
cristian: jakub, which hash tree exactly?
anyway, the capture I am having is handcrafted to produce one _large_ chain
list behind the _same_ hash bucket. so everything reduces to operations on that
list.
I was curious about the performance in this peculiar case.
what led me to this? some capture with sip packets (generated by a _real_ sip
testing tool) which had exactly this problem as well.
pretty much offtopic: does any of you know why the hash tables in glib do NOT
provide support for handling the chain lists (for collisions)?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.