On Mon, Oct 11, 1999 at 09:34:50AM +0100, Nick Lamb <njl98r@xxxxxxxxxxxxxxx> wrote:
> On Sun, 10 Oct 1999, Federico Mena Quintero wrote:
>
> > lseek() returns the offset to which you seeked, so lseek (swap_fd, 0,
> > SEEK_END) will give you its size.
>
> I think this will just give you the LENGTH of the file? So, I don't
> know if it matters, but ISTR that Gimp uses files with holes, and
> therefore LENGTH != SIZE.
Are you sure about that (that gimp uses files with holes?) a (very
shallow) look through the swapping functions seems to indicate that gimp
just grows the file as needed and allocates the swap space using a simple
list allocator.
What make sme think, couldn't swapping be greatly improved under the
following assumptions:
- the swap file is most probably linearly organized on the medium (if
the os is anything tospeak of)
- the tile swap-in order is dominated by near tiles, i.e. the next
tile swapped in is "near" the previous tile.
If these hold it might be advantageous to allocate swap space by drawable
and use morton or hilbert order within the region, so tiles that are near
each other are also near each other on the disk.
(It might also be good to reallocate the swap file for some size)
Well, we are in feature freeze...
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
