>David Cottrell wrote:
>> 
>> Alain's reply here led me to another related issue what happens if I set
>> the handle size in advance and then add something to the container?
>> 
>> I have found adding to containers is quite slow and I assume it is the
>> "growing" part which is slow. If I could set the container size to some
>> large arbitrary size first and then fill it it should be faster. Of
>> course maybe the added string would still end up being put on the end of
>> an otherwise empty block of memory.
>>
>I would say in that case, you should better work with a regular
>handle if you need to do that.
>Here is an example that sets the size of a container in advance:
>
David,

Here is another, easier, approach that may or may not be a good solution. 
It tries to trick the memory manager into organizing memory so that it 
won't have to be moved while your container is growing. It allocates a 
block to your container handle large enough to accept the expected data, 
then it reduces the official handle size on the theory that there should 
be no reason to move other blocks into the newly-released area. Resizing 
the handle as the container is enlarged should be simply a matter of 
record keeping rather than moving memory.

I couldn't tell a big difference in the little tests that I did, but you 
might try it on one of your time gobblers and see what happens.

 e-e
 =J= a  y
  "

clear local mode
'~   FN preallocate( myContainer, bytesToAdd )
local fn preallocate( @ c as ptr, bytes as long )
'Jay A Reeve, 3/02
dim size
long if c.0&
size = fn gethandlesize( c.0& )
sethandlesize( c.0&, size + bytes )
xelse
c.0& = fn newhandle( bytes )
end if
if fn memerror then shutdown "Can't preallocate for container"
sethandlesize( c.0&, size )
end fn
'~'7