efficiency

[Hannah Schroeter]

Hello!

On Mon, Dec 04, 2000 at 06:15:45PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <simonmar at microsoft.com> pisze:

> > Ok, so the malloc/free is the most expensive part.  I'm moderately
> > surprised:)  Perhaps we could do a better job, but we'll never do
> > better than ByteArrays as long as the bracket is required.

> BTW, withCString in my implementation which handles charsets does not
> use alloca but malloc. It's because we don't know the length of the
> resulting char[] until we convert it, so we cannot preallocate it.
> We must guess an initial size and realloc the array as needed.

> Hence unfortunately speeding up alloca won't speed my implementation
> of the common need of allocating C objects.

That's sad. In fact, I think it would not be too difficult to have some
extensable allocation mechanism like:
  alloca_begin :: (Addr -> IO a) -> IO a
    -- or what is the currently en vogue pointer type
Run an action in the context of an extensible allocation. Restrict
memory allocations to only "normal heap" ones (to allow more efficient
implementation) until either the action ends or an explicit alloca_end
is executed.
  alloca_extend :: Int -> IO () -- or another appropriate integer type
Extend the currently open allocation by a specified number of bytes
  alloca_end :: IO ()
finalize the currently open allocation. After that, you may use
nested alloca_begin's.

Kind regards,

Hannah.