writing image segments directly to disk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

writing image segments directly to disk

Avi  Bryant
Here's a speed/memory tradeoff that would help me a lot if I was able
to choose it: currently, the primitive that builds an image segment
requires a pre-allocated WordArray.  If you're creating an image
segment of a significant portion of the data in the image, this
effectively doubles your image size (or more, because it
over-allocates).  It would be great to have a version of this
primitive that used a file instead.  I realize that there's a lot of
random access of the buffer that goes on, which means that a
file-based prim is going to be a *lot* slower than the memory based
one, but in some cases I'm willing to pay that price to keep the image
size low.

If someone is up for writing this prim, I'm happy to compensate them
for their time.

Cheers,
Avi

Reply | Threaded
Open this post in threaded view
|

Re: writing image segments directly to disk

Klaus D. Witzel
Hi Avi,

since a swap (page) file has a disk component, it is possibly sufficient  
to just allocate from the OS's virtual memory, as part of the [enhanced]  
primitive. Then the code which now works on the pre-allocate WordArray  
might be reused as-is. Of course the swap (page) file size must reflect  
the corresponding OS memory allocation. Besides code re-use, speed might  
be another advantage when using the OS's virtual memory services.

/Klaus

On Tue, 19 Dec 2006 08:30:37 +0100, Avi Bryant wrote:

> Here's a speed/memory tradeoff that would help me a lot if I was able
> to choose it: currently, the primitive that builds an image segment
> requires a pre-allocated WordArray.  If you're creating an image
> segment of a significant portion of the data in the image, this
> effectively doubles your image size (or more, because it
> over-allocates).  It would be great to have a version of this
> primitive that used a file instead.  I realize that there's a lot of
> random access of the buffer that goes on, which means that a
> file-based prim is going to be a *lot* slower than the memory based
> one, but in some cases I'm willing to pay that price to keep the image
> size low.
>
> If someone is up for writing this prim, I'm happy to compensate them
> for their time.
>
> Cheers,
> Avi
>
>