Re: [ethereal-dev] Ethereal memory leakage fix and feature enhancement

[Guy Harris <gharris@xxxxxxxxxxxx>]

> Some time ago, I made an improvement of the snprintf function (see
> http://ethereal.zing.org/lists/ethereal-dev/199905/msg00108.html) because
> some profiling tests show me that it was a particularly good point to
> enhance.

Unfortunately, that helps only on platforms that don't have a version of
"snprintf()"; on platforms that do, we use that one, rather than ours.

> I think that the heavy use of some GTK functions also contributes
> significantly to this loss of performance but I can't see really how since
> the GTK library was not profiled when I performed the tests.

The heavy use of certain GLib functions sure as heck does; here's the
flat-profile part of the result of running a profiled, statically-linked
version of Ethereal to read a big file:

granularity: each sample hit covers 4 byte(s) for 0.00% of 33.17 seconds

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 45.4      15.05    15.05                             g_list_nth [1]
 43.7      29.55    14.50                             g_list_last [2]
  2.8      30.48     0.94                             .mcount (480)
  0.9      30.78     0.29    97592     0.00     0.01  vfprintf [13]
  0.7      31.01     0.24   195802     0.00     0.00  strncpy [18]
  0.6      31.20     0.19    20293     0.01     0.01  _gettimeofday [22]
  0.3      31.31     0.11    19913     0.01     0.01  _poll [31]
  0.3      31.40     0.09   164148     0.00     0.00  malloc_bytes <cycle 1> [33]
  0.3      31.49     0.08   234221     0.00     0.00  __sfvwrite [24]
  0.2      31.56     0.08   417290     0.00     0.00  memcpy [35]

Unfortunately, attempts to get the Nth element of a GList are linear in
N, which means that if you, say, do something such as

	for (i = 0; i < M; M++)
		xxx = g_list_nth(list, i);

you have something quadratic in M....

Many, quite possibly most, such sequences would work much better if,
say, a GList cached the index of, and pointer to, the last element
fetched with such a "g_list_xxx()" call, and, if the index in the next
call was greater than or equal to the index of the last element fetched,
started the scan at that element.  (It would, of course, flush the cache
as necessary if the list changes.)

A GtkCList, as I remember, does those sorts of sequences.