From Cristian Constantin:

while caching the last element from the conversation hash chain lists speeds-up
the operation when the hash/chain lists are actually built, it 
does NOT help a lot when a certain random conversation which is in the hash
table is looked-up.

I did some profiling and tracing and I saw that a lot of cpu time is spent in
the function conversation_lookup_hashtable() when wireshark
is asked to show the "Flow Graph", "TCP Conversations", "Voip Calls".  I used
two types of captures with over 500k packets:

- tcp packets having the _same_ src ip addr, src tcp port, dst ip addr, dst tcp 
  port
- (mostly) sip packets containing sdp payloads which advertise the _same_ ip
  addr, udp port for media

these types of captures lead to _huge_ chain lists behind the same hash bucket 
(to which the conversation is actually mapped)

the solution would be to cache the last found conversation into the head of the 
chain list and to use it whenever it is possible; most of the time the look-up
will be in O(1) instead of O(n) (n - number
of elements in the list).

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7149

svn path=/trunk/; revision=42141

1 files changed, 2 insertions, 0 deletions

diff --git a/epan/conversation.h b/epan/conversation.h
index f7a0f38dd3..9d46525d48 100644
--- a/epan/conversation.h
+++ b/epan/conversation.h
@@ -72,6 +72,8 @@ typedef struct conversation_key {
 typedef struct conversation {
 	struct conversation *next;	/** pointer to next conversation on hash chain */
 	struct conversation *last;	/** pointer to the last conversation on hash chain */
+	struct conversation *latest_found;
+								/** pointer to the last conversation on hash chain */
 	guint32	index;				/** unique ID for conversation */
 	guint32 setup_frame;		/** frame number that setup this conversation */
 	GSList *data_list;			/** list of data associated with conversation */