https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7149
Evan Huus <eapache@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eapache@xxxxxxxxx
--- Comment #8 from Evan Huus <eapache@xxxxxxxxx> 2012-04-19 11:24:21 PDT ---
Cristian, could you please post a link to one of your test files (or at least a
subsection thereof)? None of the captures I have or can create are large enough
to reliably test the timing, and there are a few experiments I'd like to run.
Also, as per my comment on the bug which originally spawned this conversation,
I'm surprised that the last pointer isn't sufficient? New packets in a sane
capture should always be going at the end of the list, which is already fast
due to the 'last' pointer that was already in place before your patch. While I
don't doubt that the slowdown is there, I think a clearer understanding of why
we're not just jumping straight to the end of the list might help.
My best guess at why we'd be hitting a slowdown here is if there's code that's
trying to iterate through all the elements in the chain in order by calling
conversation_lookup_hashtable() for each element. Do we perhaps need a function
conversation_lookup_hashchain() that returns the entire list, or a function
conversation_foreach() that calls a function for each conversation, instead?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
