From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-10-03T22:25:45+09:00
Subject: Re: tuples versus arrays


"Mauricio Fern�ndez" <batsman.geo@yahoo.com> wrote in message
news:20021003104503.GC1129@kodos...
> On Thu, Oct 03, 2002 at 02:06:30PM +0900, Bulat Ziganshin wrote:
> > Hello Mauricio,

> > better approach - using special blocks for allocating 1-20 byte areas,
> > and one common block for all areas larger. tuple is not only one
> > structure with fixed size which ryby VM has to allocate
> >
>
> This is quite easy to implement in Ruby right now, but I don't know how
> big a speed increase we'd see. malloc and friends have been subject to
> serious optimization so it won't be easy to beat them even with a more
> specific allocator.

malloc is constrained by synchronization issues - for that reason alone it
pays off to customize allocation when you know your threads.

I have an unsynchronized (you can of course add sync.) block allocation that
is pretty fast. It was originally posted in Dr.Dobbs Journal as smart alloc
and I made a few changes. It creates a chained list of pools for each size
and by default create blocks that are powers of two - and uses standard
malloc above a certain size. There is virtually no space overhead in the
allocation thanks to aligned pointer arithmetic.
Also, by default it uses logarithm from requested size to locate the right
pool. However, if you always allocate a known size that you have a dedicated
pool for - you can skip the pool selection step and get faster allocation.
For small strings, you don't know the size smallest larger pool size and you
do want the pool selection logic. I've seen fairly decent speedups on a copy
on write string class using this allocation.

If interested let me know - drop the "-anti-spam" from my mail address.
mikkelfj-anti-spam@bigfoot.com

Mikkel