Re: Is GStringChunk still useful?

[Hans Petter Jansson <hpj novell com>]

On Tue, 2006-11-07 at 02:49 -0500, mark mark mielke cc wrote:
> On Mon, Nov 06, 2006 at 09:30:17PM -0600, Hans Petter Jansson wrote:
> > On Mon, 2006-11-06 at 22:28 -0500, mark mark mielke cc wrote:
> > > On Mon, Nov 06, 2006 at 08:55:49PM -0600, Hans Petter Jansson wrote:

> > > > I seriously doubt that GStringChunk is useful, because the gain from
> > > > using non-aligned memory is lost if your strings don't fit the block
> > > > size (e.g. too long strings as described by Jeff, or even just the last
> > > > block not being completely filled). I'm in favor of obsoleting
> > > > GStringChunk.

> > > If true, then you should be able to prove it, and nothing is preventing
> > > GStringChunk from returning aligned memory.
> > > Are you guessing?

> > As stated, it depends on the use case.

> Did you try it? :-)
> 
> Cache lines are often 64 bytes or longer with modern processors.  If
> the malloc() header is 16 bytes, and the string is padded to 16 bytes
> boundaries, this can mean that a string with length 20 bytes takes up
> 48 bytes. Two such 20 bytes may be separately allocated on different
> pages, leading to a read of 128 bytes or more for two strings. Packed
> tightly, 3 x 20 bytes can fit in one 64 byte cache line. Aligned or
> un-aligned, reading fewer cache lines is cheaper.
> 
> I've recently measured the effect of alignment on Intel Xeon and AMD
> X2 processors for string operations (strpcpy() to be exact), and the
> effect is only slight.
> 
> This is why I suggest that any claims be shown with some sort of
> benchmark. The opposite may be true than what was claimed.

When I said that "the gain from using non-aligned memory is lost", I was
referring to malloc() returning aligned memory, and saying that using
non-aligned memory for strings (i.e. packing them) is a _good_ thing. So
I guess we're in agreement here :)

The loss is incurred when your blocks are not completely filled.
However, see below.

> > That's why I said long-lived. If the data is allocated and kept around
> > for a long time, the space saved is more important than the CPU time
> > lost.

> Long lived doesn't mean frequently accessed. As a long time user of
> Perl, and Java, I can say with some certainty that space utilization
> is not usually a primary concern.

That depends entirely on the device you're running it on.

Morten's Gnumeric use case has changed my mind regarding GStringChunk,
though - if we can amend the documentation to point out that the blocks
must be much larger than the expected string size, and that care should
be taken to use few GStrinkChunk allocators in an app (so there won't be
a lot of half-empty "tail blocks" left around), I think we're good.

-- 
Hans Petter