Re: g_slice considered awesome.

["Robert G. Brown" <rgb phy duke edu>]

On Fri, 4 Aug 2006, Dan Williams wrote:

> On Thu, 2006-08-03 at 20:33 -0400, Robert Love wrote:
> > Party people,
> >
> > I did some preliminary testing[1] the other day with beaglefs[2], to
> > measure the performance gain or hit from using glib's new memory
> > slices[3].
>
> If there aren't any objections, why not start using it in HEAD, since
> 0.7 isn't going to be ready next week or next month.  By the time it
> gets out later this year, I think we can rely on distros that adopt it
> to have the right versions of glib.

Let me be the devil's advocate here, not because I truly object but to
bring out the cons, which thus far haven't been discussed.  I use FC as
a distro and can therefore track the FC release pretty closely and
probably won't experience any of the cons directly, but there are others
using other distros (or not wanting to upgrade even FC all that fast).
It isn't just a matter of "gslice is faster" that makes it better, after
all.  Other factors come into play as well.

Is it insanely difficult to instrument the patch with glib revision
ifdefs or the like (so that it is easy/automagic to build independent of
the glib it is being built for)?  One thing that has been very visible
with NM development so far has been its intolerance of older (OS/distro)
revisions in its support libraries.  It might be worth it to try to
smooth this out a bit, especially with "elective" changes, as the
product matures.  Recently it has been working so perfectly (at least
for me:-) that I'm starting to think of it as being relatively mature
except for details associated with specific interfaces or layers -- TKIP
vs AES in WPA, for example, where one or the other sometimes fails and I
haven't figured out why or where.

In the specific case of gslice vs malloc, lmbench suggests that malloc
-- slower than gslice as it might be in its optimal mileau -- is very,
very fast compared to the actual performance bottlenecks in NM or for
that matter pretty much any network application (typical TCP latencies
being in the 10's to 100's of microseconds, malloc and zeroing of 100K
blocks involving less than a microsecond according to lmbench on a
fairly pedestrian laptop). Humans are largely insensitive to one-time
delays starting up some application or wireless connection that is
anything less than 0.1 seconds or thereabouts if not more.  Individual
users will, I think, almost certainly never be able to interactively
detect on the basis of experiential performance what kind of memory
allocation is being used by NM even if they try scientifically and
rather hard.  If this is true, why bother making the change?

In general, I'd say that one should depart from posix compliant, very
standard/portable calls for memory management or pretty much anything
else in code development only if there is an immediate and signficant
payoff in MEASURABLY improved performance or ease of programming.  I
suspect that this is not the case in this instance, and even if there is
one still has to look hard at the tradeoff in terms of portability
(distro-backwards or otherwise) as it factors into long-run cost/benefit
of the change as well.

Just a thought.

   rgb

--
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb phy duke edu