| From: Jeff Morriss
|
| Guy Harris wrote:
|
| > On Thu, Dec 04, 2003 at 07:46:48PM -0500, Jeff Morriss wrote:
| >
| >>where 'packet_list_find_row_from_data()' does a linear search of the
| >>rows and then returns the row number.
| >>
| >>The attached patch changes this function to make a (cheap) educated
| >>guess
| >
| >
| > Or, rather, it changes the GTK+ function it calls,
| > "gtk_clist_find_row_from_data()".
| >
| > Unfortunately, that helps only if we're using our modified
| GTK+; that's
| > not possible on some platforms that have GTK+ 1.2[.x]
| installed (e.g.,
| > AIX), and it's also not possible if you're not using GTK+
| 1.2[.x], as is
| > the case on Windows (we use 1.3[.x] or 2.x) or on UN*X with
| GTK+ 2.x.
|
| <sigh>
|
| I admit that when I was looking into this I was disheartened
| when I very
| quickly ran into the gtk*() functions, but then I found the
| source code
| and when I modified the source code it worked (both on Linux and
| Solaris) so I figured they weren't really Gtk+ functions after all...
|
| Interestingly, I do have Gtk+ 1.2.10 installed but I was still using
| Ethereal's modified Gtk routines.
|
| At any rate... Ouch, these clists have a painful API!
|
| (Since I imagine there's a lot of gtk-1.2 users out
| there--sunfreeware.com still hasn't released gtk-2.x
| packages!--would it
| be worth putting in this optimization anyway? What about
| pursuing the
| other optimizations I was looking at? I know it's kinda
| dirty, but as
| Didier said in the initial post, the current behavior is completely
| unusable with large captures.)
May I suggest to hide the actual GtkCList stuff with macros as a first
optimization? We then could decide to incorporate our CList code instead of
the Gtk code...
Regards,
Olivier