Wireshark-bugs: [Wireshark-bugs] [Bug 3246] RTP stream analysis finding next non-ok very slow at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3246
--- Comment #4 from Christoph Furer <christoph.furer@xxxxxxxxxxxx> 2009-02-11 06:00:02 PDT ---
I now know, why it is as slow:
In "rtp_analysis.c" Next non-OK has this code:
----
while (gtk_clist_get_text(clist,row,6,&text)) {
if (strcmp(text, OK_TEXT) != 0) {
gtk_clist_select_row(clist, row, 0);
gtk_clist_moveto(clist, row, 0, 0.5, 0);
return;
}
++row;
----
This means, for every packet, gtk_clist_get_text is called.
In "ethlist.c" the function for gtk_clist_get_text (eth_clist_get_text) has
this code:
----
clist_row = ROW_ELEMENT (clist, row)->data;
----
ROW_ELEMENT is defined in "ethlist.c" as follows:
-----
#define ROW_ELEMENT(clist, row) (((row) == (clist)->rows - 1) ? \
(clist)->row_list_end : \
g_list_nth ((clist)->row_list, (row)))
----
In "glist.c" (GLIB), g_list_nth has the following code:
----
GList*
g_list_nth (GList *list,
guint n)
{
while ((n-- > 0) && list)
list = list->next;
return list;
}
----
This means, that for every packet, the list is started from the beginning up to
the nth packet to get the text, then the same for the next packet etc.
Assuming I am at packet 150000 and want to find a sequence error at packet
160000, the code will first go through packets 1 to 150001, compare the text,
then from 1 to 150002, compare the text etc. Of course this is not very
efficient. Would it be a solution, to have an additional pointer to the packet
list pointing to the actual packet (not only to the beginning of the list) and
start the search from there on? I don't know if it is possible, but it would
reduce the computing time drastically!
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
